Open Interpreter

codex_file_search is a high-performance fuzzy file search tool designed for Codex. It provides fast directory traversal and pattern matching to locate files within a codebase.

Key Technical Details:

• Directory Traversal: Uses the ignore crate to traverse directories while respecting .gitignore files and other ignore patterns (similar to ripgrep).
• Fuzzy Matching: Uses the nucleo-matcher crate to perform fuzzy matching of a user-supplied PATTERN against the discovered file list.

Open Interpreter is a programming agent optimized for low-cost models. Key capabilities include:

• Command Execution: Runs commands with native isolation on macOS, Linux, and Windows.
• Model Management: Change providers and models directly from the TUI using /model.
• Harness Inspection: Inspect or change native Rust model harnesses using /harness.
• Computer Use (QA): Includes QA abilities to operate and test interfaces. It can control web applications via agent-browser or native applications via trycua.
• Protocol Support: Functions as an Agent Client Protocol (ACP) agent via interpreter acp. It is compatible with exec, MCP, skills, hooks, permissions, and AGENTS.md.
• Persistence: Maintains configuration and session state in ~/.openinterpreter.

codex-tools is a shared support crate designed for building, adapting, and executing model-visible tools outside of codex-core. It provides the host-facing tool models, discovery mechanisms, and adapters required to prepare tools for model consumption.

Key responsibilities include:

• Aggregate Host Models: Managing models like ToolSpec, ConfiguredToolSpec, LoadableToolSpec, ResponsesApiNamespace, and ResponsesApiNamespaceTool.
• Host Discovery: Providing models for discoverable tools and helpers for request-plugin-install workflows.
• Host Adapters: Handling schema sanitization, MCP/dynamic conversion, code-mode augmentation, and image-detail normalization.
• Executable-Tool Contracts: Defining shared interfaces such as ToolExecutor, ToolCall, and ToolOutput.

The codex-api crate provides typed clients for Codex/OpenAI APIs, handling request/response models, provider configuration (base URLs, headers, query params), auth header injection, and SSE stream parsing. It serves as the wire-level layer for codex-core.

The interface is divided into three primary functional areas:

1. Responses endpoint: For generating model responses via streaming.
2. Compaction endpoint: For compressing conversation history.
3. Memory summarize endpoint: For summarizing raw memories into structured outputs.

All HTTP-level details like retry policies, backoff, and SSE framing are encapsulated, allowing callers to work with high-level protocol types.

Open Interpreter can be used across several domains by providing it with a concrete workspace, clear constraints, and a verification target. Common tasks include:

Engineering

• Fixing bugs using reproduction steps.
• Explaining unfamiliar code paths.
• Refactoring modules while maintaining existing behavior.
• Adding tests for regressions.
• Upgrading dependencies or API integrations.
• Synchronizing documentation with code changes.

Review and Quality

• Reviewing pull request diffs.
• Auditing security-sensitive code.
• Triaging failing CI logs.
• Converting flaky-test reports into actionable fix plans.

Data and Docs

• Analyzing CSV or log exports within a disposable workspace.
• Drafting internal documentation based on source files.
• Converting issue threads into implementation tasks.

Once installed, you can extend or control Open Interpreter using the following features:

• Slash commands: Manage sessions and switch models directly from the composer.
• AGENTS.md: Provide project-specific guidance that the agent reads automatically.
• Skills: Create and package reusable workflows for the agent to use.
• Sandbox & approvals: Configure the environment to decide which commands run automatically versus which require manual approval.
• Harness mode: Use harness-shaped compatibility modes for specific integration needs.
• CLI Reference: Access the full suite of interpreter commands and flags.

The codex-app-server-client crate provides a shared in-process client used to manage the lifecycle of a codex-app-server runtime. It is designed for conversational CLI surfaces like codex-exec and codex-tui to centralize startup, handshake, and transport wiring without duplicating logic.

Key responsibilities include:

• Bootstrapping and initializing the app-server handshake.
• Wiring in-memory request/event transport.
• Orchestrating lifecycle management based on a caller-provided startup identity.
• Managing graceful shutdown behavior.

The codex-http-client crate is the centralized low-level HTTP transport for all Codex crates. Instead of constructing reqwest::Client directly, product crates should use the types provided by this crate to ensure consistent outbound request policies, connection pooling, and proxy handling.

Key responsibilities of this crate include:

• Managing request, response, streaming, and transport types.
• Handling custom CA certificates via CODEX_CA_CERTIFICATE and SSL_CERT_FILE.
• Implementing outbound proxy policies (System, PAC/WPAD, Environment, or Direct).
• Providing route-aware client pooling and redirect handling.
• Injecting tracing headers and request diagnostics.
• Managing the opt-in ChatGPT Cloudflare cookie store.

The codex-client crate provides a high-level request policy layer built on top of codex-http-client. It is designed to handle common networking concerns without requiring specific knowledge of Codex or OpenAI APIs.

Key capabilities include:

• Retry Utilities: Provides RetryPolicy, RetryOn, run_with_retry, and backoff to manage unary and streaming calls.
• SSE Streaming: Supplies the sse_stream helper to transform byte streams into raw SSE data: frames, including support for idle timeouts and surfaced stream errors.
• Telemetry: Defines the request telemetry callback interface used by higher-level clients.
• Migration Support: Temporarily re-exports low-level HTTP types from codex-http-client to allow for incremental migration.

The Python SDK provides two primary public surfaces for interacting with Codex:

• Synchronous Surface: Use the Codex class for standard blocking calls. Found in sync.py examples.
• Asynchronous Surface: Use the AsyncCodex class for non-blocking, async/await workflows. Found in async.py examples.

All examples rely exclusively on public exports from openai_codex and openai_codex.types. Input can be provided as plain strings for text-only turns or as typed input objects for multimodal (e.g., image + text) or structured input lists.