mirror of
https://github.com/openai/codex.git
synced 2026-09-14 11:57:03 +00:00
52dd39bc95
Add exec-server filesystem RPCs and a core-side remote filesystem client, then route unified-exec and filesystem-backed tools through that backend when enabled by config. Also add Docker-backed remote exec integration coverage for the local codex-exec CLI. Co-authored-by: Codex <noreply@openai.com>
102 lines
4.7 KiB
Markdown
102 lines
4.7 KiB
Markdown
# Configuration
|
|
|
|
For basic configuration instructions, see [this documentation](https://developers.openai.com/codex/config-basic).
|
|
|
|
For advanced configuration instructions, see [this documentation](https://developers.openai.com/codex/config-advanced).
|
|
|
|
For a full configuration reference, see [this documentation](https://developers.openai.com/codex/config-reference).
|
|
|
|
## Connecting to MCP servers
|
|
|
|
Codex can connect to MCP servers configured in `~/.codex/config.toml`. See the configuration reference for the latest MCP server options:
|
|
|
|
- https://developers.openai.com/codex/config-reference
|
|
|
|
## Apps (Connectors)
|
|
|
|
Use `$` in the composer to insert a ChatGPT connector; the popover lists accessible
|
|
apps. The `/apps` command lists available and installed apps. Connected apps appear first
|
|
and are labeled as connected; others are marked as can be installed.
|
|
|
|
## Notify
|
|
|
|
Codex can run a notification hook when the agent finishes a turn. See the configuration reference for the latest notification settings:
|
|
|
|
- https://developers.openai.com/codex/config-reference
|
|
|
|
When Codex knows which client started the turn, the legacy notify JSON payload also includes a top-level `client` field. The TUI reports `codex-tui`, and the app server reports the `clientInfo.name` value from `initialize`.
|
|
|
|
## JSON Schema
|
|
|
|
The generated JSON Schema for `config.toml` lives at `codex-rs/core/config.schema.json`.
|
|
|
|
## SQLite State DB
|
|
|
|
Codex stores the SQLite-backed state DB under `sqlite_home` (config key) or the
|
|
`CODEX_SQLITE_HOME` environment variable. When unset, WorkspaceWrite sandbox
|
|
sessions default to a temp directory; other modes default to `CODEX_HOME`.
|
|
|
|
## Custom CA Certificates
|
|
|
|
Codex can trust a custom root CA bundle for outbound HTTPS and secure websocket
|
|
connections when enterprise proxies or gateways intercept TLS. This applies to
|
|
login flows and to Codex's other external connections, including Codex
|
|
components that build reqwest clients or secure websocket clients through the
|
|
shared `codex-client` CA-loading path and remote MCP connections that use it.
|
|
|
|
Set `CODEX_CA_CERTIFICATE` to the path of a PEM file containing one or more
|
|
certificate blocks to use a Codex-specific CA bundle. If
|
|
`CODEX_CA_CERTIFICATE` is unset, Codex falls back to `SSL_CERT_FILE`. If
|
|
neither variable is set, Codex uses the system root certificates.
|
|
|
|
`CODEX_CA_CERTIFICATE` takes precedence over `SSL_CERT_FILE`. Empty values are
|
|
treated as unset.
|
|
|
|
The PEM file may contain multiple certificates. Codex also tolerates OpenSSL
|
|
`TRUSTED CERTIFICATE` labels and ignores well-formed `X509 CRL` sections in the
|
|
same bundle. If the file is empty, unreadable, or malformed, the affected Codex
|
|
HTTP or secure websocket connection reports a user-facing error that points
|
|
back to these environment variables.
|
|
|
|
## Notices
|
|
|
|
Codex stores "do not show again" flags for some UI prompts under the `[notice]` table.
|
|
|
|
## Plan mode defaults
|
|
|
|
`plan_mode_reasoning_effort` lets you set a Plan-mode-specific default reasoning
|
|
effort override. When unset, Plan mode uses the built-in Plan preset default
|
|
(currently `medium`). When explicitly set (including `none`), it overrides the
|
|
Plan preset. The string value `none` means "no reasoning" (an explicit Plan
|
|
override), not "inherit the global default". There is currently no separate
|
|
config value for "follow the global default in Plan mode".
|
|
|
|
## Realtime start instructions
|
|
|
|
`experimental_realtime_start_instructions` lets you replace the built-in
|
|
developer message Codex inserts when realtime becomes active. It only affects
|
|
the realtime start message in prompt history and does not change websocket
|
|
backend prompt settings or the realtime end/inactive message.
|
|
|
|
## Unified exec over exec-server
|
|
|
|
`experimental_unified_exec_use_exec_server` routes unified-exec process
|
|
launches and filesystem-backed tools through `codex-exec-server` instead of
|
|
using only the local in-process implementations.
|
|
|
|
When `experimental_unified_exec_exec_server_websocket_url` is set, Codex
|
|
connects to that existing websocket endpoint and uses it for both unified-exec
|
|
processes and remote filesystem operations such as `read_file`, `list_dir`, and
|
|
`view_image`.
|
|
|
|
When `experimental_unified_exec_spawn_local_exec_server` is also enabled, Codex
|
|
starts a session-scoped local `codex-exec-server` subprocess on startup and
|
|
uses that connection for the same process and filesystem calls.
|
|
|
|
`experimental_supported_tools` can be used to opt specific experimental tools
|
|
into the tool list even when the selected model catalog entry does not advertise
|
|
them. This is useful when testing remote filesystem-backed tools such as
|
|
`read_file` and `list_dir` against an exec-server-backed environment.
|
|
|
|
Ctrl+C/Ctrl+D quitting uses a ~1 second double-press hint (`ctrl + c again to quit`).
|