Codex's IDE extension is useful where the task is closely tied to the editor: to the current selection, open files, diagnostics and symbol navigation. It uses the local Codex runtime and the shared config but adds commands and settings specific to the editor. The point of the extension is to bring the agent closer to the context you already work in, not to create a separate universe: the core of behavior is shared with the CLI, only the ways to supply context and present the result differ.

The key subtlety is that context does not get into the editor by itself. What is open in the editor is not obliged to automatically become the model's context. To add the selection or open files to the next prompt, you use an IDE command or /ide. This is a conscious distinction: the editor may show dozens of files, but the agent will see only what you explicitly passed. Expecting that "it sees my screen anyway" is a frequent mistake leading to requests where the agent lacks context you thought was passed.

Selection as context is a powerful technique that requires discipline. It helps to see such a request once. Below is a wording that takes the current selection as a failing function: first find callers and tests in the workspace, do not change neighboring modules until the execution path is shown. The selection sets a precise entry point, while the boundaries in the request keep the agent from spreading. Precise context plus an explicit boundary is what makes work in the IDE targeted rather than vague.

The shared policy in the IDE is the same as in the CLI, and this matters to understand. The user ~/.codex/config.toml, a trusted project's .codex/config.toml, AGENTS.md, skills and MCP are available by the same core rules as in the terminal. The extension does not set up a separate trust model or override the sandbox in its own way: it takes boundaries from the shared layers. So a policy configured once works the same in the editor and the CLI - provided you keep it in the shared config rather than in editor-specific settings.

The extension's boundary runs along presentation and integration, not the core. Editor-specific commands and settings manage how context is supplied and how the result is shown: the selection, open files, inline presentation. But the model, sandbox, approvals and MCP are taken from the shared layers. This separation is worth keeping in mind: if the agent's behavior is wrong, look for the cause in the shared config, not the editor settings, and if supplying context is inconvenient - conversely, in the editor-specific part.