mirror of https://github.com/pchuan98/codex.git synced 2026-07-01 00:31:56 +08:00

Files

T

Owen Lin 6ea041032b fix(core): prevent hanging turn/start due to websocket warming issues (#14838 )

## Description

This PR fixes a bad first-turn failure mode in app-server when the
startup websocket prewarm hangs. Before this change, `initialize ->
thread/start -> turn/start` could sit behind the prewarm for up to five
minutes, so the client would not see `turn/started`, and even
`turn/interrupt` would block because the turn had not actually started
yet.

Now, we:
- set a (configurable) timeout of 15s for websocket startup time,
exposed as `websocket_startup_timeout_ms` in config.toml
- `turn/started` is sent immediately on `turn/start` even if the
websocket is still connecting
- `turn/interrupt` can be used to cancel a turn that is still waiting on
the websocket warmup
- the turn task will wait for the full 15s websocket warming timeout
before falling back

## Why

The old behavior made app-server feel stuck at exactly the moment the
client expects turn lifecycle events to start flowing. That was
especially painful for external clients, because from their point of
view the server had accepted the request but then went silent for
minutes.

## Configuring the websocket startup timeout
Can set it in config.toml like this:
```
[model_providers.openai]
supports_websockets = true
websocket_connect_timeout_ms = 15000
```

6ea041032b · 2026-03-17 10:07:46 -07:00

History

src

fix(core): prevent hanging turn/start due to websocket warming issues (#14838 )

2026-03-17 10:07:46 -07:00

templates

[apps] Add tool call meta. (#14647 )

2026-03-14 22:24:13 -07:00

tests

fix(core): prevent hanging turn/start due to websocket warming issues (#14838 )

2026-03-17 10:07:46 -07:00

BUILD.bazel

Move TUI on top of app server (parallel code) (#14717 )

2026-03-16 10:49:19 -06:00

Cargo.toml

[apps] Add tool_suggest tool. (#14287 )

2026-03-11 22:06:59 -07:00

config.schema.json

fix(core): prevent hanging turn/start due to websocket warming issues (#14838 )

2026-03-17 10:07:46 -07:00

gpt_5_1_prompt.md

Assemble sandbox/approval/network prompts dynamically (#8961 )

2026-01-12 23:12:59 +00:00

gpt_5_2_prompt.md

Assemble sandbox/approval/network prompts dynamically (#8961 )

2026-01-12 23:12:59 +00:00

gpt_5_codex_prompt.md

Assemble sandbox/approval/network prompts dynamically (#8961 )

2026-01-12 23:12:59 +00:00

gpt-5.1-codex-max_prompt.md

Assemble sandbox/approval/network prompts dynamically (#8961 )

2026-01-12 23:12:59 +00:00

gpt-5.2-codex_prompt.md

Assemble sandbox/approval/network prompts dynamically (#8961 )

2026-01-12 23:12:59 +00:00

hierarchical_agents_message.md

Add hierarchical agent prompt (#8996 )

2026-01-09 13:47:37 -08:00

models.json

Update models.json (#13617 )

2026-03-05 16:22:39 -08:00

prompt_with_apply_patch_instructions.md

Assemble sandbox/approval/network prompts dynamically (#8961 )

2026-01-12 23:12:59 +00:00

prompt.md

Assemble sandbox/approval/network prompts dynamically (#8961 )

2026-01-12 23:12:59 +00:00

README.md

fix: reopen writable linux carveouts under denied parents (#14514 )

2026-03-13 01:36:06 +00:00

review_prompt.md

docs: Fix markdown list item spacing in codex-rs/core/review_prompt.md (#4144 )

2025-10-30 17:39:21 -07:00

README.md

codex-core

This crate implements the business logic for Codex. It is designed to be used by the various Codex UIs written in Rust.

Dependencies

Note that codex-core makes some assumptions about certain helper utilities being available in the environment. Currently, this support matrix is:

macOS

Expects /usr/bin/sandbox-exec to be present.

When using the workspace-write sandbox policy, the Seatbelt profile allows writes under the configured writable roots while keeping .git (directory or pointer file), the resolved gitdir: target, and .codex read-only.

Network access and filesystem read/write roots are controlled by SandboxPolicy. Seatbelt consumes the resolved policy and enforces it.

Seatbelt also supports macOS permission-profile extensions layered on top of SandboxPolicy:

no extension profile provided: keeps legacy default preferences read access (user-preference-read).
extension profile provided with no macos_preferences grant: does not add preferences access clauses.
macos_preferences = "readonly": enables cfprefs read clauses and user-preference-read.
macos_preferences = "readwrite": includes readonly clauses plus user-preference-write and cfprefs shm write clauses.
macos_automation = true: enables broad Apple Events send permissions.
macos_automation = ["com.apple.Notes", ...]: enables Apple Events send only to listed bundle IDs.
macos_launch_services = true: enables LaunchServices lookups and open/launch operations.
macos_accessibility = true: enables com.apple.axserver mach lookup.
macos_calendar = true: enables com.apple.CalendarAgent mach lookup.
macos_contacts = "read_only": enables Address Book read access and Contacts read services.
macos_contacts = "read_write": includes the readonly Contacts clauses plus Address Book writes and keychain/temp helpers required for writes.

Linux

Expects the binary containing codex-core to run the equivalent of codex sandbox linux (legacy alias: codex debug landlock) when arg0 is codex-linux-sandbox. See the codex-arg0 crate for details.

Legacy SandboxPolicy / sandbox_mode configs are still supported on Linux. They can continue to use the legacy Landlock path when the split filesystem policy is sandbox-equivalent to the legacy model after cwd resolution.

Split filesystem policies that need direct FileSystemSandboxPolicy enforcement, such as read-only or denied carveouts under a broader writable root, automatically route through bubblewrap. The legacy Landlock path is used only when the split filesystem policy round-trips through the legacy SandboxPolicy model without changing semantics. That includes overlapping cases like /repo = write, /repo/a = none, /repo/a/b = write, where the more specific writable child must reopen under a denied parent.

All Platforms

Expects the binary containing codex-core to simulate the virtual apply_patch CLI when arg1 is --codex-run-as-apply-patch. See the codex-arg0 crate for details.