{ "schemaVersion": 3, "dataset": { "version": 3, "date": "2026-08-13", "group": { "id": "coding-agent-infrastructure", "name": "Coding-Agent Infrastructure" }, "repository": { "id": "codex", "repo": "openai/codex", "name": "Codex", "keywords": [ "OpenAI Codex" ] }, "context": { "repository": "openai/codex", "url": "https://github.com/openai/codex", "description": "Lightweight coding agent that runs in your terminal", "language": "Rust", "topics": [], "license": "Apache-2.0", "defaultBranch": "main", "stars": 105729, "forks": 16037, "openIssues": 12486, "archived": false, "collectedAt": "2026-08-13T18:02:22.700129+00:00" }, "news": { "repository": "openai/codex", "collectedAt": "2026-08-13T18:02:22.700129+00:00", "latestRelease": { "repository": "openai/codex", "tag": "rust-v0.147.0", "title": "0.147.0", "url": "https://github.com/openai/codex/releases/tag/rust-v0.147.0", "publishedAt": "2026-08-07T01:41:49Z", "notes": "## New Features\n- Install portable Agent Plugins and search across local, personal, workspace, and remote plugin catalogs. (#36544, #36409, #36919, #36796)\n- Organize conversations into persistent, manually ordered sections and browse long transcripts incrementally. (#35722, #36007, #36380, #36948, #36950)\n- Enable automatically reviewed approvals with the new `--approve-for-me` CLI flag. (#36373)\n- Import Cursor-managed skills and synchronize changes to imported Claude and Cursor conversations without creating duplicates. (#36361, #36356, #35623)\n- Support the opt-in MCP 2026-07-28 protocol, including paginated discovery, multi-round requests, and non-blocking server startup. (#35724, #35725, #35590, #35742)\n- Enable cached web search and remote conversation compaction for Amazon Bedrock. (#36938, #36981)\n\n## Bug Fixes\n- Redact secrets and complete bearer tokens from displayed commands and replayed conversation history. (#36893, #36908)\n- Prevent lost or stalled terminal input when focus returns, MCP servers initialize, or Ghostty handles keyboard shortcuts. (#35649, #35957, #36834)\n- Correct rendering and cursor positioning for Japanese characters, emoji, hyperlinks, and text near viewport boundaries. (#35960, #35962, #37166)\n- Properly interrupt Windows background processes and handle Windows filesystem paths consistently. (#35655, #35851, #37129)\n- Require explicit trust for unfamiliar local projects and enforce managed authentication restrictions before credentials are used. (#36960, #37132)\n- Harden plugin isolation and deny network access when policy updates fail. (#37027, #36967, #36037)\n\n## Documentation\n- Improve the bundled OpenAI documentation skill with targeted official-source lookup and clearer guidance for Codex, model selection, and API workflows. (#36014)\n\n## Chores\n- Upgrade the MCP SDK to 3.0.0, Ratatui to 0.30.2, and V8 to 150.4.0. (#36001, #35959, #35831)\n- Secure macOS release notarization using Azure Key Vault instead of exporting private signing keys. (#37154)\n- Remove the deprecated `codex exec --full-auto` flag; use `--sandbox workspace-write` instead. (#36054)\n- Stop publishing redundant Linux bundle archives; use the standard `codex-package-` release archives. (#36342)\n\n## Changelog\n\nFull Changelog: https://github.com/openai/codex/compare/rust-v0.146.0...rust-v0.147.0\n\n- #35590 Expose cached MCP tools before server startup @copyberry\n- #35594 Recommend longer waits in the v2 wait_agent schema @copyberry\n- #35595 Allow alpha hotfix versions in R2 releases @copyberry\n- #35597 Add metrics for extension-rendered skill catalogs @copyberry\n- #35607 Record metrics for empty skill catalogs @copyberry\n- #35608 Support model-owned token budget defaults @copyberry\n- #35621 Skip restored token usage replay for exec resumes @copyberry\n- #35623 Parse Claude and Cursor session records separately @copyberry\n- #35642 Make OpenTelemetry provider shutdown idempotent @copyberry\n- #35644 Preserve thread metadata when rollout files are missing @copyberry\n- #35649 Preserve TUI input when terminal focus returns @copyberry\n- #35652 Enable network policy callbacks for remote exec @copyberry\n- #35653 Test developer instruction inheritance for multi-agent workers @copyberry\n- #35655 Terminate Windows non-TTY processes on interrupt @copyberry\n- #35656 Preserve multi-agent settings across config representations @copyberry\n- #35661 Place host skills before permission instructions @copyberry\n- #35663 Evaluate character matching over skill routing metadata @copyberry\n- #35665 Fix the async watcher test harness on Windows @copyberry\n- #35668 Expose the network proxy spec constructor @copyberry\n- #35670 Raise the Windows exec yield floor to 10 seconds @copyberry\n- #35671 Route curated plugins by authentication mode @copyberry\n- #35675 Prepare MCP and plugin recommendations concurrently @copyberry\n- #35678 Preserve paginated thread metadata across resumes @copyberry\n- #35685 Load cloud-managed profiles for `codex sandbox` @copyberry\n- #35688 Point crossterm patch to the OpenAI OSS fork @copyberry\n- #35689 Preserve item timestamps in thread history projections @copyberry\n- #35691 Include empty-preview threads in relationship listings @copyberry\n- #35693 Refresh the subagent picker in the background @copyberry\n- #35695 Honor the configured SQLite home in the logs client @copyberry\n- #35708 Add configurable developer instructions for v2 subagents @copyberry\n- #35715 Support streaming bodies in route-aware HTTP requests @copyberry\n- #35717 Reuse route-aware clients for OpenAI file uploads @copyberry\n- #35720 Upgrade rmcp to 3.0.0-beta.3 @copyberry\n- #35721 Honor disabled code mode fallback without a process host @copyberry\n- #35722 Add persisted sections for organizing threads @copyberry\n- #35724 Add MCP 2026-07-28 discovery support @copyberry\n- #35725 Complete MCP 2026 client support @copyberry\n- #35738 Add bounded metadata for executed tool calls @copyberry\n- #35742 Avoid blocking turns on optional MCP startup @copyberry\n- #35744 Keep agent registry identities consistent @copyberry\n- #35766 Emit host skill budget warnings from world state @copyberry\n- #35769 Share the skills budget across host and executor catalogs @copyberry\n- #35772 Throttle models cache TTL renewals @copyberry\n- #35773 Scale skill metadata budgets with context windows @copyberry\n- #35777 Resolve MCP tool catalogs concurrently @copyberry\n- #35779 Load thread titles concurrently during session startup @copyberry\n- #35785 Support self-serve Business ProLite accounts @copyberry\n- #35787 Gate paginated thread history on the state database @copyberry\n- #35794 Wait for MCP readiness in the curated sync test @copyberry\n- #35802 Tag reports with the selected turn's model and effort @copyberry\n- #35806 Route MCP OAuth through configured HTTP clients @copyberry\n- #35814 Use configured HTTP clients for all MCP OAuth requests @copyberry\n- #35818 Advance latest-alpha-cli after release publishing completes @copyberry\n- #35821 Use the shared HTTP client for TUI network checks @copyberry\n- #35825 Use the shared HTTP client for announcement tips @copyberry\n- #35828 Enforce centralized SQLite connection creation @copyberry\n- #35830 Route WebRTC sideband joins to the Realtime API @copyberry\n- #35831 Update rusty_v8 to 150.4.0 @copyberry\n- #35835 Track parent turns for nested Codex requests @copyberry\n- #35836 Clean up cancelled MCP elicitation requests @copyberry\n- #35837 Expose plugin eligibility metadata in app-server summaries @copyberry\n- #35839 Decouple recommended plugins from tool suggestions @copyberry\n- #35840 Handle legacy MCP discovery prevalidation errors @copyberry\n- #35843 Tie remote exec servers to their parent stdin @copyberry\n- #35845 Support plaintext collaboration tool messages @copyberry\n- #35850 Preserve foreign paths in background terminal listings @copyberry\n- #35851 Normalize Windows namespace paths in path URIs @copyberry\n- #35854 Box app-server event payloads @copyberry\n- #35856 Resolve imported connectors by MCP server name @copyberry\n- #35857 Add Bazel unit test targets for Rust binaries @copyberry\n- #35859 Expose plugin installation timestamps in app-server summaries @copyberry\n- #35870 Include session titles in external agent import history @copyberry\n- #35874 Mark the primary environment in model context @copyberry\n- #35875 Allow environment readiness updates in place @copyberry\n- #35878 Use step environments for MCP file uploads @copyberry\n- #35886 Show blocked goals as stalled in the TUI @copyberry\n- #35887 Clean up side conversations in the background @copyberry\n- #35895 Inherit ready step environments when spawning agents @copyberry\n- #35937 Let unrelated tools run while MCP servers start @copyberry\n- #35941 Bound MCP namespace descriptions @copyberry\n- #35942 Update tests for current tool call and app-server event types @copyberry\n- #35944 Report direct input capability for listed subagents @copyberry\n- #35957 Fix TUI input queue handling during MCP startup @copyberry\n- #35959 Upgrade Ratatui to 0.30.2 @copyberry\n- #35960 Preserve hyperlink cell widths during terminal diffing @copyberry\n- #35962 Fix TUI layout for halfwidth Japanese sound marks @copyberry\n- #35982 Avoid cloning rollout history when truncating forks @copyberry\n- #35989 Display title-only reasoning summaries in the TUI @copyberry\n- #35990 Test exec-server compatibility across Codex versions @copyberry\n- #35992 Group external agent config migration into a module @copyberry\n- #35997 Remove obsolete rusty_v8 146.4.0 Bazel targets @copyberry\n- #36001 Upgrade rmcp to 3.0.0 @copyberry\n- #36002 Resolve MCP file uploads with environment-native paths @copyberry\n- #36006 Reduce response serialization and rollout scan overhead @copyberry\n- #36007 Add persisted manual ordering for thread sections @copyberry\n- #36008 Route pet asset downloads through the shared HTTP client @copyberry\n- #36011 Share optional MCP startup grace across connection sets @copyberry\n- #36014 Refine OpenAI docs skill source routing @copyberry\n- #36020 Avoid cloning ignored analytics notifications @copyberry\n- #36030 Increase the app-server tracing test stack size @copyberry\n- #36031 Load cloud-managed servers in MCP CLI commands @copyberry\n- #36033 Use the shared HTTP client in codex-protocol @copyberry\n- #36035 Exit the stdio app-server when its connection closes @copyberry\n- #36036 Allow naming forked chats from the TUI @copyberry\n- #36037 Deny network access when an allow amendment fails @copyberry\n- #36039 Limit MCP catalog pagination @copyberry\n- #36043 Document the Responses API proxy reqwest exception @copyberry\n- #36045 Distinguish unknown MCP authentication status @copyberry\n- #36047 Extract MCP environment headers into a local variable @copyberry\n- #36049 Keep tool-call metrics out of Statsig exports @copyberry\n- #36051 Avoid overwriting symlinked migration targets @copyberry\n- #36054 Remove legacy `--full-auto` handling from `codex exec` @copyberry\n- #36055 Expose MCP read-only hints in tool call items @copyberry\n- #36076 Remove codex-core's direct reqwest dependency @copyberry\n- #36078 Route Ollama through the shared HTTP client @copyberry\n- #36083 Handle fractional rate limits in thread history projection @copyberry\n- #36092 Correlate image requests and explicit interrupts with turns @copyberry\n- #36119 Unify tool runtime assembly before router construction @copyberry\n- #36120 Delegate readiness waits to tool runtimes @copyberry\n- #36121 Sandbox executor skill resource reads @copyberry\n- #36124 Respect filesystem permissions during capability discovery @copyberry\n- #36127 Centralize tool registration and protect host tools @copyberry\n- #36128 Preserve delegated tasks across remote compaction @copyberry\n- #36129 Resolve normalized tool name collisions in code mode @copyberry\n- #36133 Preserve executor workspace permissions for apply_patch @copyberry\n- #36138 Isolate apply-patch permission test variants @copyberry\n- #36139 Bound the code mode output termination test @copyberry\n- #36140 Wait for memory consolidation shutdown before finishing jobs @copyberry\n- #36146 Stabilize approval scenario tests @copyberry\n- #36148 Harden the file change approval integration test @copyberry\n- #36149 Strengthen session file change approval coverage @copyberry\n- #36165 Stabilize file approval replay test @copyberry\n- #36166 Make pending realtime sideband test deterministic @copyberry\n- #36167 Harden the auto-review model override test @copyberry\n- #36168 Make tool telemetry tag collection synchronous @copyberry\n- #36171 Test workspace-root patch protection for metadata @copyberry\n- #36177 Test remote Guardian network approval scoping @copyberry\n- #36181 Record attempted tool calls in response metadata @copyberry\n- #36183 Use permission profiles throughout sandbox execution @copyberry\n- #36184 Coalesce concurrent remote metadata requests @copyberry\n- #36187 Refresh environment dates from the configured clock @copyberry\n- #36188 Make thread history projection resilient to malformed rollouts @copyberry\n- #36191 Label explicit skill injection metrics @copyberry\n- #36194 Avoid shifting bytes in streaming output buffers @copyberry\n- #36207 Record normalized sandbox violation events @copyberry\n- #36212 Precompute app-server protocol exports @copyberry\n- #36217 Run code mode exclusively through the standalone host @copyberry\n- #36218 Expose connector candidates in external agent detection @copyberry\n- #36221 Ignore passthrough metadata when reconciling rollout items @copyberry\n- #36223 Preserve executor paths in read command actions @copyberry\n- #36228 Support Enterprise automation account plans @copyberry\n- #36237 Ignore symbolic slash-tmp permissions on Windows @copyberry\n- #36239 Refresh precomputed app-server protocol exports @copyberry\n- #36264 Prefer the bundled resource for the code mode host @copyberry\n- #36271 Derive report prompt hashes from persisted rollouts @copyberry\n- #36306 Restrict hosted MCP credentials to local environments @copyberry\n- #36309 Use the host skill provider catalog in world state @copyberry\n- #36310 Isolate MCP OAuth credentials by environment @copyberry\n- #36311 Include skills in debug prompt input output @copyberry\n- #36327 Preserve discovery order for host skill path aliases @copyberry\n- #36329 Restrict `shell_command` to a single local environment @copyberry\n- #36336 Detect connectors used in external agent sessions @copyberry\n- #36339 Enable skills in the MCP server @copyberry\n- #36342 Stop publishing legacy Linux bundle archives @copyberry\n- #36350 Require explicit sandbox permissions with shell justifications @copyberry\n- #36351 Use model catalog collaboration mode messages @copyberry\n- #36354 Pass sessions directly to session tasks @copyberry\n- #36355 Keep MCP tool calls bound to their thread @copyberry\n- #36356 Sync updates to imported external agent sessions @copyberry\n- #36357 Use the step-scoped router for tool execution @copyberry\n- #36359 Consolidate MCP config editing in codex-core @copyberry\n- #36360 Use MCP bindings as the step tool catalog @copyberry\n- #36361 Migrate Cursor-managed skills into Codex @copyberry\n- #36364 Move skill catalog rendering out of core @copyberry\n- #36365 Add strict automatic review for MCP elicitations @copyberry\n- #36367 Keep effective tool exposure in the registry @copyberry\n- #36372 Run native Windows Bazel tests with MSVC @copyberry\n- #36373 Add an `--approve-for-me` CLI flag @copyberry\n- #36374 Enable sandboxed V8 for code mode @copyberry\n- #36378 Load local session pickers from the state DB first @copyberry\n- #36380 Add thread section management APIs @copyberry\n- #36384 Load turn summaries with paginated queries @copyberry\n- #36385 Add acknowledged user message submission to core @copyberry\n- #36388 Track image preparation details in turn analytics @copyberry\n- #36389 Enforce single-writer ownership for all thread histories @copyberry\n- #36393 Avoid redundant filesystem probes @copyberry\n- #36402 Declare the experimental plugin search API @copyberry\n- #36408 Allow custom Codex instructions for realtime transitions @copyberry\n- #36409 Implement remote plugin search @copyberry\n- #36410 Make user input blocking behavior explicit @copyberry\n- #36411 Use Git repositories as pre-tool hook test markers @copyberry\n- #36413 Add a realtime delegation acknowledgement control @copyberry\n- #36440 Extract exec-server request dispatching @copyberry\n- #36482 Avoid querying terminal size on every TUI redraw @copyberry\n- #36485 Increase remote plugin bundle size limits @copyberry\n- #36507 Retain attempted tool metadata across prompts @copyberry\n- #36511 Support two-stroke TUI key chords @copyberry\n- #36534 Raise the MCP catalog item limit to 2,048 @copyberry\n- #36544 Support portable Agent Plugins throughout installation @copyberry\n- #36632 Preserve SQLite thread metadata during goal mutations @copyberry\n- #36635 Expose onboarding hints in login completion notifications @copyberry\n- #36641 Capture rollout budget units from response usage @copyberry\n- #36715 Use provider-reported rollout budget units @copyberry\n- #36716 Deduplicate MCP resource operation handling @copyberry\n- #36727 Simplify turn metadata state ownership @copyberry\n- #36729 Correlate code mode tool analytics with model responses @copyberry\n- #36732 Stabilize the cloud environment HTTP test @copyberry\n- #36734 Deduplicate MCP resource list handling @copyberry\n- #36740 Store turn skill state in extension data @copyberry\n- #36742 Simplify contextual user fragment registration @copyberry\n- #36744 Store the extension registry directly in its builder @copyberry\n- #36745 Consolidate apply_patch runtime execution @copyberry\n- #36757 Wait for patch events before reading shell snapshots @copyberry\n- #36759 Harden the TUI focus palette regression test @copyberry\n- #36764 Avoid building code-mode definitions during registration @copyberry\n- #36769 Stabilize the startup Git enrichment integration test @copyberry\n- #36770 Stabilize deferred goal fork testing @copyberry\n- #36771 Harden Linux managed proxy helper lifecycles @copyberry\n- #36772 Raise the host-owned Codex Apps catalog limit @copyberry\n- #36773 Derive the active user config layer from the layer stack @copyberry\n- #36774 Clarify config layer iteration APIs @copyberry\n- #36779 Stabilize network policy event capture in concurrent tests @copyberry\n- #36781 Add per-surface MCP tool exposure controls @copyberry\n- #36782 Add Guardian session reuse and interruption tests @copyberry\n- #36787 Consolidate model instructions in `ModelMessages` @copyberry\n- #36792 Gate plugin usage instructions by model capability @copyberry\n- #36793 Terminate timed-out Git process trees @copyberry\n- #36796 Add Agent Plugins MCP config parsing @copyberry\n- #36797 Normalize rusty_v8 checksum manifest line endings @copyberry\n- #36800 Avoid reinjecting permissions after command approvals @copyberry\n- #36807 Extract audio preparation into a utility crate @copyberry\n- #36808 Prefer SQLite names for local session archive commands @copyberry\n- #36809 Prefer the state database for `exec resume --last` @copyberry\n- #36810 Add MCP client conformance regression gates @copyberry\n- #36811 Honor per-environment login shell policy @copyberry\n- #36812 Add a dual-WebSocket transport for code mode @copyberry\n- #36815 Identify agents by name in token budget context @copyberry\n- #36822 Fix typo in approval resolver name @copyberry\n- #36825 Consolidate approval telemetry context @copyberry\n- #36830 Time out stalled code-mode host requests @copyberry\n- #36834 Avoid requesting key-release events in Ghostty @copyberry\n- #36840 Keep API request metrics out of Statsig exports @copyberry\n- #36856 Support deferred loading for freeform tools @copyberry\n- #36857 Support custom tools in namespaces @copyberry\n- #36862 Consolidate thread spawning behind a request object @copyberry\n- #36871 Parallelize R2 asset publishing with DotSlash @copyberry\n- #36877 Move executor skill bundle loading into the skills extension @copyberry\n- #36880 Move direct executor skill discovery into the skills extension @copyberry\n- #36882 Preserve complete MCP namespace descriptions @copyberry\n- #36884 Add host skill root loading @copyberry\n- #36892 Support leaf models in multi-agent v2 @copyberry\n- #36893 Redact secrets from app-server command execution items @copyberry\n- #36895 Handle late MCP startup results after lag timeout @copyberry\n- #36898 Avoid redundant filesystem metadata probes @copyberry\n- #36900 Register app tools independently of the connector list @copyberry\n- #36901 Propagate updated permissions to review threads @copyberry\n- #36903 Load skill interface metadata in the host loader @copyberry\n- #36904 Limit RMCP logs persisted to SQLite @copyberry\n- #36906 Preserve model providers when reloading v2 agents @copyberry\n- #36908 Improve bearer token secret redaction @copyberry\n- #36910 Negotiate MCP extensions per app-server session @copyberry\n- #36912 Read approval policy from the current turn configuration @copyberry\n- #36913 Move skill policy resolution into `codex-skills` @copyberry\n- #36916 Centralize app enabled-state evaluation @copyberry\n- #36917 Test explicit plugin mentions with disabled apps @copyberry\n- #36919 Merge local plugins into plugin search results @copyberry\n- #36921 Move the host skills service into the skills extension @copyberry\n- #36924 Reject implicitly discovered bare Git repositories @copyberry\n- #36930 Read turn permissions from the current configuration @copyberry\n- #36935 Trust undecided local projects automatically @copyberry\n- #36938 Enable cached web search for Amazon Bedrock @copyberry\n- #36939 Include policy approval reasons in Guardian reviews @copyberry\n- #36941 Use current session settings for review threads @copyberry\n- #36943 Move host skill root resolution into the skills extension @copyberry\n- #36945 Grant the blob size policy job read access to contents @copyberry\n- #36947 Accept user input when starting idle turns @copyberry\n- #36948 Paginate transcript history in the TUI @copyberry\n- #36949 Improve paginated TUI history loading @copyberry\n- #36950 Paginate TUI transcript history @copyberry\n- #36951 Harden paginated history handling in the TUI @copyberry\n- #36952 Add durable per-thread user submission queues @copyberry\n- #36954 Add tool registry collision policy configuration @copyberry\n- #36956 Keep image resize notices attached during remote compaction @copyberry\n- #36959 Track connectors detected in external agent sessions @copyberry\n- #36960 Prompt before trusting local project directories @copyberry\n- #36963 Link Codex attribution in pull request bodies @copyberry\n- #36964 Preserve working directories when importing external sessions @copyberry\n- #36966 Allow disabling the built-in image viewer @copyberry\n- #36967 Skip symlinks when installing plugins @copyberry\n- #36970 Make token budget context identity configurable @copyberry\n- #36976 Honor explicit-only orchestrator skills @copyberry\n- #36977 Improve connector detection for migrated sessions @copyberry\n- #36979 Add Fence auditing to the blob size workflow @copyberry\n- #36981 Enable remote compaction for Amazon Bedrock @copyberry\n- #36983 Preserve ChatGPT auth for trusted staging MCP servers @copyberry\n- #36984 Support configured ChatGPT cookies in HTTP clients @copyberry\n- #36986 Add process-scoped PSP routing for ChatGPT requests @copyberry\n- #36987 Add opt-in concurrent exec-server request dispatch @copyberry\n- #36989 Preserve shared bundled skill caches @copyberry\n- #36990 Remove legacy collaboration mode variants @copyberry\n- #36992 Allow injecting model catalog caches @copyberry\n- #36993 Support `includeTurns` reads for paginated threads @copyberry\n- #36998 Support deferred custom tools in tool search @copyberry\n- #37000 Keep shared skill caches fresh across plugin loads @copyberry\n- #37020 Enforce strict tool name collision errors @copyberry\n- #37022 Canonicalize default tools under the `functions` namespace @copyberry\n- #37027 Enforce Agent Plugin runtime boundaries @copyberry\n- #37031 Apply permission profile updates to future turn environments @copyberry\n- #37035 Align registry tests with canonical tool names @copyberry\n- #37038 Use turn environment permissions for tool execution @copyberry\n- #37040 Use turn environment permissions for context and discovery @copyberry\n- #37053 Reject conflicting namespace descriptions in strict tool mode @copyberry\n- #37055 Add safer TUI defaults for cyber models @copyberry\n- #37066 Preserve longer MCP source descriptions in tool search @copyberry\n- #37068 Fall back to per-process MCP cleanup on macOS @copyberry\n- #37083 Consolidate unified exec output state @copyberry\n- #37101 Reuse stable MCP bindings across sampling steps @copyberry\n- #37103 Use Luna for API-key Guardian reviews @copyberry\n- #37109 Bound interactive telemetry shutdown @copyberry\n- #37114 Add per-session code-mode execution limits @copyberry\n- #37128 Centralize tool approval handling in `Session` @copyberry\n- #37129 Make Windows path URI comparisons ASCII-case-insensitive @copyberry\n- #37132 Enforce managed authentication requirements locally @copyberry\n- #37134 Report prompt image resizing to the model @copyberry\n- #37144 Preserve discovery paths for symlinked skills @copyberry\n- #37145 Gate Apps usage instructions by model capability @copyberry\n- #37147 Track provisioned environment state across registration @copyberry\n- #37149 Project orchestrator skills through world state @copyberry\n- #37151 Coalesce concurrent Git status scans @copyberry\n- #37154 Use Azure Key Vault for macOS notarization @copyberry\n- #37156 Test remote environments reported ready before selection @copyberry\n- #37157 Harden named session lookup in the TUI @copyberry\n- #37162 Load host skill roots through the skills extension @copyberry\n- #37166 Keep textarea cursors and rendering inside the viewport @copyberry\n- #37167 Expose session sources to MCP contributors @copyberry\n- #37168 Bound remote MCP handshake HTTP requests @copyberry\n- #37169 Move plugin skill snapshot integration tests into core @copyberry\n- #37174 Centralize skill invocation helpers in `codex-skills` @copyberry\n- #37175 Add legacy rollout migration to paginated history @copyberry\n- #37177 Move explicit skill selection into the skills crate @copyberry\n- #37178 Preserve image transparency metadata in app-server items @copyberry\n- #37188 Reserve the `tool_search` namespace for the search tool @copyberry\n- #37189 Track multi-agent usage hints in world state @copyberry\n\n\n", "highlights": [ "New Features", "Install portable Agent Plugins and search across local, personal, workspace, and remote plugin catalogs. (#36544, #36409, #36919, #36796)", "Organize conversations into persistent, manually ordered sections and browse long transcripts incrementally. (#35722, #36007, #36380, #36948, #36950)", "Enable automatically reviewed approvals with the new --approve-for-me CLI flag. (#36373)", "Import Cursor-managed skills and synchronize changes to imported Claude and Cursor conversations without creating duplicates. (#36361, #36356, #35623)", "Support the opt-in MCP 2026-07-28 protocol, including paginated discovery, multi-round requests, and non-blocking server startup. (#35724, #35725, #35590, #35742)" ], "prerelease": false }, "upcoming": [ { "repository": "openai/codex", "kind": "prerelease", "title": "0.148.0-alpha.12", "url": "https://github.com/openai/codex/releases/tag/rust-v0.148.0-alpha.12", "description": "Release 0.148.0-alpha.12\n\n", "tag": "rust-v0.148.0-alpha.12", "publishedAt": "2026-08-13T06:43:33Z" }, { "repository": "openai/codex", "kind": "prerelease", "title": "0.148.0-alpha.11", "url": "https://github.com/openai/codex/releases/tag/rust-v0.148.0-alpha.11", "description": "Release 0.148.0-alpha.11\n\n", "tag": "rust-v0.148.0-alpha.11", "publishedAt": "2026-08-13T04:11:00Z" }, { "repository": "openai/codex", "kind": "prerelease", "title": "0.148.0-alpha.9", "url": "https://github.com/openai/codex/releases/tag/rust-v0.148.0-alpha.9", "description": "Release 0.148.0-alpha.9\n\n", "tag": "rust-v0.148.0-alpha.9", "publishedAt": "2026-08-12T01:35:53Z" } ], "communityDiscussions": [] }, "runs": [ { "collectedAt": "2026-08-13T12:26:38.318Z", "since": "2026-08-12T12:26:38.318Z", "observedCount": 407, "changedCount": 407 }, { "collectedAt": "2026-08-13T13:48:00.446149Z", "since": "2026-08-12T13:48:00.446149Z", "observedCount": 403, "changedCount": 403 }, { "collectedAt": "2026-08-13T16:19:22.035158Z", "since": "2026-08-12T16:19:22.035158Z", "observedCount": 411, "changedCount": 64 }, { "collectedAt": "2026-08-13T17:43:20.785491Z", "since": "2026-08-12T17:43:20.785491Z", "observedCount": 405, "changedCount": 24 }, { "collectedAt": "2026-08-13T17:47:07.884300Z", "since": "2026-08-12T17:47:07.884300Z", "observedCount": 405, "changedCount": 1 }, { "collectedAt": "2026-08-13T18:01:55.420671Z", "since": "2026-08-12T18:01:55.420671Z", "observedCount": 407, "changedCount": 5 } ], "signals": [ { "id": "github:openai/codex:issue:10384", "source": "github", "group": "coding-agent-infrastructure", "project": "openai/codex", "kind": "issue", "title": "Make request_user_input tool available in code mode", "text": "### What version of Codex is running? 0.93 ### What subscription do you have? GPT Plus ### Which model were you using? gpt-5.2 ### What platform is your computer? Linux ### What terminal emulator and version are you using (if applicable)? _No response_ ### What issue are you seeing? request_user_input tool is not available in code mode: error `request_user_input is unavailable in code mode` ### What steps can reproduce the bug? 1. turn on collaboration_modes = true 2. run codex, switch to code mode, ask agent to use request_user_input tool ### What is the expected behavior? agent can use tool request_user_input tool ### Additional information request_user_input tool is not available in code mode, only in plan mode (request_user_input is unavailable in code mode)", "url": "https://github.com/openai/codex/issues/10384", "timestamp": "2026-08-12T12:56:51Z", "metrics": { "reactions": 132, "comments": 28 }, "labels": [ "enhancement", "tool-calls" ], "author": "vbp1", "assignees": [], "change": "new" }, { "id": "github:openai/codex:issue:10469", "source": "github", "group": "coding-agent-infrastructure", "project": "openai/codex", "kind": "issue", "title": "Codex app: Allow both queueing and interrupting (i.e. steering) in desktop app", "text": "### What feature would you like to see? The terminal allows one to 'tab' to queue and 'return' to interrupt with steering turned on. Please allow this in the desktop app as I use both regularly within the same session. ### Additional information _No response_", "url": "https://github.com/openai/codex/issues/10469", "createdAt": "2026-02-03T04:05:12Z", "updatedAt": "2026-08-12T20:31:49Z", "timestamp": "2026-08-12T20:31:49Z", "metrics": { "reactions": 5, "comments": 2 }, "labels": [ "enhancement", "app" ], "author": "guidedways", "state": "closed", "assignees": [] }, { "id": "github:openai/codex:issue:11023", "source": "github", "group": "coding-agent-infrastructure", "project": "openai/codex", "kind": "issue", "title": "Codex desktop app for Linux", "text": "### What variant of Codex are you using? App ### What feature would you like to see? I love the new codex app. However due to [this issue](https://github.com/openai/codex/issues/10432) it is almost unusable on my mac laptop. I would like to use the app on my linux desktop where power consumption is far less of an issue. ### Additional information _No response_", "url": "https://github.com/openai/codex/issues/11023", "createdAt": "2026-02-07T17:34:16Z", "updatedAt": "2026-08-13T17:58:20Z", "timestamp": "2026-08-13T17:58:20Z", "metrics": { "reactions": 1463, "comments": 209 }, "labels": [ "enhancement", "app" ], "author": "Suhaibinator", "state": "closed", "assignees": [], "change": "new" }, { "id": "github:openai/codex:issue:11604", "source": "github", "group": "coding-agent-infrastructure", "project": "openai/codex", "kind": "issue", "title": "Add configurable audible alert for pending permission approvals in Codex CLI", "text": "### What variant of Codex are you using? CLI ### What feature would you like to see? I’d like to request an improvement for Codex CLI: play a configurable audible alert whenever the agent requests a permission approval (similar to Copilot CLI). **Why this helps** During long-running tasks, I’m not always watching the terminal. Approval prompts can be missed, which adds unnecessary delay. **Proposed behavior** - Add a config option: approval_sound (on/off) - Optionally allow: - choosing sound type/volume - using system notification sound - repeating alert every X seconds while approval is pending **Expected outcome** Faster response to approval prompts and smoother human-in-the-loop workflows. ### Additional information _No response_", "url": "https://github.com/openai/codex/issues/11604", "createdAt": "2026-02-12T16:48:49Z", "updatedAt": "2026-08-13T00:09:22Z", "timestamp": "2026-08-13T00:09:22Z", "metrics": { "reactions": 0, "comments": 3 }, "labels": [ "enhancement", "sandbox", "CLI" ], "author": "you-apps-code", "state": "closed", "assignees": [] }, { "id": "github:openai/codex:issue:11966", "source": "github", "group": "coding-agent-infrastructure", "project": "openai/codex", "kind": "issue", "title": "Odd content injection", "text": "### What version of Codex CLI is running? 0.101.0 ### What subscription do you have? Pro ### Which model were you using? gpt-5.3-codex xhigh ### What platform is your computer? Darwin 25.2.0 arm64 arm ### What terminal emulator and version are you using (if applicable)? JetBrains ### What issue are you seeing? I'm using the following prompt: ``` --- allowed-tools: AskUserQuestion, Read, Glob, Grep, Write, Edit argument-hint: [plan-file] description: Interview to flesh out a plan/spec --- Here's the current plan: @$ARGUMENTS Interview me in detail using the AskUserQuestion tool about literally anything: technical implementation, UI & UX, concerns, tradeoffs, etc. but make sure the questions are not obvious. Make sure to add a state machine and or flow chat of the plan. Also add a brief summary in for overall overview. Be very in-depth and continue interviewing me continually until it's complete, then write the spec back to `$ARGUMENTS`. ``` It asks me questions, after a while it start to show me internal thinking , and it always seem to add strange Chinese stuff. I translated it and it seems to be consistently lottery, betting etc. For example: ``` 11. For Swagger/OpenAPI exposure, should admin endpoints be included in the same public spec/UI? A) yes, include all endpoints in one spec B) hide/exclude admin endpoints from public docs C) split into public spec + internal admin spec. +#+#+#+#+#+user to=assistant code _人人碰final 彩娱乐彩票 ``` ### What steps can reproduce the bug? Run this prompt on a plan ``` --- allowed-tools: AskUserQuestion, Read, Glob, Grep, Write, Edit argument-hint: [plan-file] description: Interview to flesh out a plan/spec --- Here's the current plan: @$ARGUMENTS Interview me in detail using the AskUserQuestion tool about literally anything: technical implementation, UI & UX, concerns, tradeoffs, etc. but make sure the questions are not obvious. Make sure to add a state machine and or flow chat of the plan. Also add a brief summary in for overall overview. Be very in-depth and continue interviewing me continually until it's complete, then write the spec back to `$ARGUMENTS`. ``` After a while it starts to go nuts. ### What is the expected behavior? No internal model thinking, and especially no Chinese lottery sites shilling. ### Additional information _No response_", "url": "https://github.com/openai/codex/issues/11966", "createdAt": "2026-02-17T07:22:59Z", "updatedAt": "2026-08-13T05:24:11Z", "timestamp": "2026-08-13T05:24:11Z", "metrics": { "reactions": 8, "comments": 12 }, "labels": [ "bug", "model-behavior", "CLI" ], "author": "ohaddahan", "state": "closed", "assignees": [] }, { "id": "github:openai/codex:issue:12382", "source": "github", "group": "coding-agent-infrastructure", "project": "openai/codex", "kind": "issue", "title": "CLI: resume can get stuck on Working after unclean disconnect/shutdown of an active turn", "text": "### What version of Codex CLI is running? `codex-cli 0.104.0` ### What subscription do you have? ChatGPT Plus ### Which model were you using? Primarily `gpt-5.3-codex` ### What platform is your computer? Linux x86_64 (`Ubuntu 25.10`, kernel `6.17.0-14-generic`) ### What terminal emulator and version are you using (if applicable)? zsh terminal on Linux ### What issue are you seeing? `codex resume ` can get stuck on `Working` for long-lived threads **after an unclean disconnect/shutdown** (for example interrupt while a tool call is still running, then close/kill session and later resume). This is thread-specific. Fresh/new sessions usually work. MCPs do not seem to be the root cause: - Repro still occurs with MCPs disabled. - Re-enabling/disabling MCP does not eliminate recurrence. ### What steps can reproduce the bug? 1. Start a long-running turn in Codex (for example a command that requires repeated polling / `write_stdin` updates). 2. Interrupt / terminate the Codex process uncleanly while that turn is still active (Ctrl+C / shutdown / disconnect). 3. Run `codex resume `. 4. Observe resume opening but staying stuck on `Working` with no progress. ### What is the expected behavior? Resume should recover cleanly from interrupted turns (or mark them aborted) and allow normal interaction, rather than remaining in a stale in-progress state. ### What is the actual behavior? The resumed thread often appears stuck in a stale in-progress state (`Working`) until manual JSONL repair. ### Evidence (from local logs/session state) Observed on **2026-02-20**: - Thread file: - stored under `~/.codex/sessions/.../rollout-*.jsonl` - size: ~`300 MB` - lines: ~`73k` - Tail boundary indicates incomplete turn: - `last_task_started=2026-02-20T22:29:02.373Z` - `last_task_complete=2026-02-20T21:35:53.389Z` - Log sequence shows unclean interruption/shutdown followed by resume + fallback warnings: - `2026-02-20T22:28:29Z` interrupt received - `2026-02-20T22:28:30Z` shutting down Codex instance - `2026-02-20T22:28:54Z` resumed rollout successfully - repeated warnings: `state db record_discrepancy: find_thread_path_by_id_str_in_subdir, falling_back` ### Workaround I can recover by trimming session JSONL to the last `event_msg task_complete` boundary (with backup), then resume works again. That workaround strongly suggests the resume path is not robust to interrupted in-flight turns. ### Related issues Possibly related to: - #11852 (stale `Working` after reconnect) - #11685 (unable to resume large conversations) ### Request Could Codex automatically harden resume against this pattern by detecting/recovering incomplete tails (e.g., `task_started` newer than `task_complete`) after unclean shutdown/disconnect?", "url": "https://github.com/openai/codex/issues/12382", "createdAt": "2026-02-20T22:49:53Z", "updatedAt": "2026-08-13T15:16:12Z", "timestamp": "2026-08-13T15:16:12Z", "metrics": { "reactions": 2, "comments": 2 }, "labels": [ "bug", "TUI" ], "author": "gabrielbryk", "state": "open", "assignees": [] }, { "id": "github:openai/codex:issue:12491", "source": "github", "group": "coding-agent-infrastructure", "project": "openai/codex", "kind": "issue", "title": "Codex.app GUI: MCP child processes not reaped after task completion — 1300+ zombies, 37GB memory leak", "text": "# Codex.app GUI: MCP child processes not reaped after task completion — 1300+ zombies, 37GB memory leak ## What version of Codex CLI is running? codex-cli 0.98.0 (Codex.app GUI wrapper) ## What subscription do you have? ChatGPT Pro ## Which model were you using? o3 (via Codex.app GUI) ## What platform is your computer? macOS 26.3 (25D125), Apple M4 Max, 64GB RAM, arm64 ## What issue are you seeing? **Codex.app spawns** `codex exec --full-auto` worker processes for each worktree but never reaps them or their MCP child processes when tasks complete. Over multiple audit sessions, this accumulated **1,319 zombie Codex processes** and **1,537 node processes** consuming **\\~37GB RSS + 40GB swap** on a 64GB machine, causing severe system-wide slowdown. ### Root cause analysis Each Codex.app task creates: * 1× `codex exec --full-auto --skip-git-repo-check --json -` (CLI worker) * 4× `oh-my-codex` MCP servers (state, memory, trace, code-intel) * 1× Serena MCP server (via `uv tool uvx`) * 1× `uv` process for Serena **≈ 7 processes per task.** None are killed when the task completes. With 12 git worktrees created by Codex.app (detached HEAD, pointing at old commits), this produced: * 12 worktrees × \\~110 child processes = **\\~1,320 sleeping processes** * Combined RSS: **\\~37GB** (mostly npm/node/uv MCP servers) * Swap usage: **39.4GB** (on 64GB physical RAM) When Codex.app (PID 19947) was killed, 2 additional `codex exec` workers (launched Friday and Saturday) were reparented to `launchd` (PPID=1), confirming they were never properly cleaned up. ### Process tree snapshot (before cleanup) ``` Codex.app (PID 19947, 279MB) ├── codex exec --full-auto (PID 19970, 123MB) │ └── 880× node/npm/uv children (27GB total) │ ├── npm (236MB each, ×2) │ ├── npm (140MB each, ×4) │ ├── uv (91MB each, ×2) │ └── node (77MB each, ×dozens) ├── Codex Helper Renderer (PID 20018, 602MB) └── Codex Helper (PID 19971, 101MB) Orphaned (PPID=1, reparented from dead Codex.app sessions): ├── codex exec --full-auto (PID 59326, Fri 23:59) │ ├── oh-my-codex/state-server.js │ ├── oh-my-codex/memory-server.js │ ├── oh-my-codex/trace-server.js │ ├── oh-my-codex/code-intel-server.js │ └── serena start-mcp-server └── codex exec --full-auto (PID 59747, Sat 22:05) └── (same MCP stack) ``` ### Memory impact | Metric | Before cleanup | After cleanup | Delta | | -- | -- | -- | -- | | Swap used | 39.4 GB | 8.0 GB | **-31 GB** | | Codex processes | 1,319 | 0 | **-100%** | | Node processes | 1,537 | 17 | **-99%** | | Free pages | 82K | 2.3M | **×28** | ### Worktree state at time of discovery All 12 worktrees were detached HEAD on old commits (2+ phases behind current main), confirming tasks had completed long ago: ``` /Users/drg/.codex/worktrees/0585/medical-ai 627d44e (detached HEAD) /Users/drg/.codex/worktrees/0b7b/medical-ai 627d44e (detached HEAD) /Users/drg/.codex/worktrees/2a60/medical-ai 4d53e7d (detached HEAD) ... (12 total, all on 2 old commits) ``` Current HEAD: `71aefff` — none of the worktrees were anywhere near current. ## What steps can reproduce the bug? 1. Use Codex.app GUI to run multiple tasks on a git repository (especially with MCP servers configured via oh-my-codex) 2. Let tasks complete normally 3. Wait a few hours / run more tasks 4. Check process count: `ps aux | grep -c codex` 5. Check memory: `ps aux | grep codex | awk '{sum+=$6} END {printf \"%.0f MB\\n\", sum/1024}'` Accumulation is proportional to number of tasks × MCP servers configured. ## What is the expected behavior? When a Codex.app task completes: 1. The `codex exec` worker process should be terminated 2. All MCP child processes (oh-my-codex servers, Serena, uv) should be killed via process group signal 3. The git worktree should be cleaned up if the task is done (or at minimum, child processes should not persist) ## What is the actual behavior? * Worker processes and their entire MCP subtree remain alive indefinitely * No cleanup occurs on task completion, app quit, or even app crash (reparented to launchd) * Memory grows unboundedly with each task ## Relationship to existing issues * [CLI-494](https://linear.app/openai/issue/CLI-494/missing-childwait-after-start-kill-creates-zombie-processes-and) (fixed, Oct 2025): `start_kill()` without `wait()` in `exec.rs` — same root cause pattern (missing process reaping), but fix only covered timeout/Ctrl+C in CLI, not GUI lifecycle * [CLI-3017](https://linear.app/openai/issue/CLI-3017/the-codex-cli-has-a-serious-memory-leak-issue-that-causes-computer) (Jan 2026): CLI memory leak causing crashes * [#12414]() (Feb 2026, open): Unbounded memory growth when idle on v0.104.0 This issue is distinct because it specifically affects **Codex.app GUI** and its interaction with **MCP server child processes** — the GUI spawns long-lived `codex exec` workers that themselves spawn MCP servers, creating a deeper process tree that the existing cleanup logic does not handle. ## Suggested fix 1. **Process group kill**: `codex exec` workers should use `setsid()` / process groups so all children (MCP servers) can be killed with a single `killpg()` on task completion 2. **Worktree lifecycle**: Codex.app should track active worktrees and clean up stale ones on startup (e.g., remove worktrees whose tasks are no longer active) 3. **Heartbeat/watchdog**: MCP servers spawned by `codex exec` should monitor their parent and self-terminate if the parent dies (check PPID periodically, or use a pipe/fd that breaks on parent death)", "url": "https://github.com/openai/codex/issues/12491", "timestamp": "2026-08-12T13:30:15Z", "metrics": { "reactions": 5, "comments": 38 }, "labels": [ "bug", "mcp", "app", "plugins" ], "author": "rolldav", "assignees": [], "change": "new" }, { "id": "github:openai/codex:issue:13114", "source": "github", "group": "coding-agent-infrastructure", "project": "openai/codex", "kind": "issue", "title": "Bug: tool-call envelope leaked into assistant text + occasional lottery/ads injection", "text": "# Bug: Tool-call envelope leaks into assistant text (+ occasional off-topic injection like lottery/ads) ## What version of Codex CLI is running? `@openai/codex` dependency in app: `^0.106.0` ## Which model were you using? `gpt-5.3-codex` (observed in local leak logs) ## What platform is your computer? macOS (Apple Silicon) ## What issue are you seeing? In GUI integration (Codex embedded via app-server/SDK), the assistant occasionally outputs tool-call envelope text as normal chat content, for example: ```text assistant to=functions.exec_command commentary json {\"cmd\":\"cat > backend/src/main/java/.../AuthController.java ...\"} ``` This should be emitted as structured tool events (`item.started`/`item.completed`) rather than visible assistant message text. Additionally, there are intermittent off-topic/injected fragments reported by users (e.g. unrelated lottery/ads-like strings such as “中彩票/买彩票”), mixed into normal output. ## Reproduction 1. Start a long coding turn with continuous follow-up prompts like `继续`. 2. Let the model execute multiple tool calls (`exec_command`, file writes, tests). 3. Occasionally, the UI receives leaked envelope text and renders it as assistant content. ## Expected behavior - Tool calls are always represented as structured tool events only. - Assistant text should never include tool-call envelope/protocol text. - No unrelated injection text (lottery/ads) should appear. ## Actual behavior - Rarely, assistant text includes protocol-like strings: - `assistant to=functions.exec_command ...` - `recipient_name: functions.exec_command ...` - In some sessions, off-topic injection text can also appear. ## Evidence - Local leak log file: - `/Users/wlkjyy/Downloads/11111/跑腿/.vibe/logs/codex-tool-envelope-leak.jsonl` - Example fields from leak entries: - `leakMarker: \"assistant_to_functions\"` - `model: \"gpt-5.3-codex\"` - `hadToolActivity: true` - `hadToolFailure: false` - `hadErrorEvent: false` - Sample leaked snippet: - `assistant to=functions.exec_command ... {\"cmd\":\"cat > ...\"}` - Additional leaked sample (same session style): - `...注册与安全配置已补完...完成后会直接联调前端并跑测试。assistant to=functions.exec_command ... {\"cmd\":\"cat > backend/src/main/java/com/vibeide/backend/module/auth/controller/AuthController.java ...\"}` ## Notes I understand similar reports were previously labeled as `model-behavior` (e.g. #11688, #11966). Reporting this again because the tool-envelope leakage still surfaces in real usage and harms UX/reliability in embedded GUI clients. If needed, I can provide thread/session IDs and additional logs.", "url": "https://github.com/openai/codex/issues/13114", "createdAt": "2026-02-28T07:47:15Z", "updatedAt": "2026-08-13T05:22:18Z", "timestamp": "2026-08-13T05:22:18Z", "metrics": { "reactions": 6, "comments": 4 }, "labels": [ "bug", "model-behavior", "CLI", "tool-calls" ], "author": "u-wlkjyy", "state": "closed", "assignees": [] }, { "id": "github:openai/codex:issue:13867", "source": "github", "group": "coding-agent-infrastructure", "project": "openai/codex", "kind": "issue", "title": "GPT-5.4 emits internal `multi_tool_use.parallel` format as plain text with training data artifacts", "text": "## Summary GPT-5.4 via the Codex CLI occasionally emits corrupted output containing internal ChatGPT tool-calling formats (`multi_tool_use.parallel` with `recipient_name`) mixed with memorized Chinese gambling SEO spam, instead of making proper Responses API tool calls. ## Reproduction - **Model:** gpt-5.4 - **Mode:** Default collaboration, reasoning effort xhigh - **Sandbox:** danger-full-access, approval_policy: never - **Context:** Normal conversation about LaTeX file structure. User said \"sure\" to confirm a plan. Model responded with content structure, then immediately emitted corrupted output. ## Corrupted output (redacted) ``` numerusformամաស to=multi_tool_use.parallel 大发时时彩是 北京赛车有json {\"tool_uses\":[{\"recipient_name\":\"functions.mcp__filesystem__search_files\",\"parameters\":{...}}]} ``` The model was trying to search a `Literature/` directory for papers by specific authors (Edmans, Back, Gorbenko, Greenwood, Burkart, Corum). Instead of issuing a proper `exec_command` tool call, it emitted the old ChatGPT `multi_tool_use.parallel` internal format as plain text, interleaved with memorized Chinese gambling SEO spam tokens (大发时时彩, 北京赛车, 彩票主管, 彩神争霸). ## Two bugs ### 1. Model-level (GPT-5.4) GPT-5.4 is leaking internal ChatGPT `multi_tool_use.parallel` scaffolding and memorized training data. The `multi_tool_use.parallel` function and `recipient_name` format are internal ChatGPT plugin-era constructs that should never appear in Responses API output. ### 2. CLI-level (Codex) Codex treated the corrupted output as plain text (`agent_message`), then **re-fed it as a `user_message`** in the next turn (visible in the rollout JSONL at lines 1117-1118). This propagated the corruption forward in the conversation context. ## Evidence - Session rollout: `rollout-2026-03-07T13-52-41-019cc892-5f52-7e32-9e62-d2c3e37d2492.jsonl`, lines 1111-1118 - Turn context: model=gpt-5.4, turn_id=019cc8d8-f18b-7333-abf3-1943f2f8629f - Timestamp: 2026-03-07T15:10:01Z ## Security concern With `danger-full-access` sandbox + `approval_policy: never`, if the `multi_tool_use.parallel` format had been recognized as a tool call rather than text, it would have auto-executed filesystem operations without user approval. The CLI should consider sanitizing or rejecting model outputs that contain known internal tool-calling formats that don't match the expected Codex tool schema.", "url": "https://github.com/openai/codex/issues/13867", "createdAt": "2026-03-07T15:42:22Z", "updatedAt": "2026-08-13T05:20:26Z", "timestamp": "2026-08-13T05:20:26Z", "metrics": { "reactions": 0, "comments": 7 }, "labels": [ "bug", "model-behavior", "sandbox", "CLI", "tool-calls" ], "author": "AustinJunyuLi", "state": "closed", "assignees": [] }, { "id": "github:openai/codex:issue:13965", "source": "github", "group": "coding-agent-infrastructure", "project": "openai/codex", "kind": "issue", "title": "apply_patch fails on Windows because Codex cannot spawn codex.exe from WindowsApps (CreateProcessAsUserW failed: 5)", "text": "### What version of the Codex App are you using (From “About Codex” dialog)? 0.108.0-alpha.12 ### What subscription do you have? plus ### What platform is your computer? Microsoft Windows NT 10.0.26100.0 x64 ### What issue are you seeing? Environment: - OS: Windows - Codex package path: C:\\Program Files\\WindowsApps\\OpenAI.Codex_26.305.950.0_x64__2p2nqsd0c76g0\\app\\resources - codex.exe file version: 0.108.0-alpha.12 - Workspace used for reproduction: E:\\Codex-test Summary: The apply_patch tool fails for both Add File and Update File operations. The failure is not caused by patch syntax, target file state, or lack of write access to the workspace. The direct cause is that the Codex runner cannot spawn codex.exe in apply-patch mode. The sandbox log shows: - ACL setup failure on the WindowsApps resources path - CreateProcessAsUserW failed: 5 - final apply_patch result surfaces only as exit code 1 Observed behavior: Any apply_patch call fails with exit code 1 and no useful diagnostic output. Expected behavior: apply_patch should successfully apply a valid patch, or at minimum return the actual underlying error. What was verified: - The workspace is writable with normal shell writes. - Creating files with PowerShell succeeds. - apply_patch fails on both Add File and Update File. - The same pattern also occurred in another workspace, so this is not specific to one repository. Direct evidence: 1. apply_patch wrapper: C:\\Users\\Admin\\.codex\\tmp\\arg0\\codex-arg092Awvx\\apply_patch.bat Contents: @echo off \"C:\\Program Files\\WindowsApps\\OpenAI.Codex_26.305.950.0_x64__2p2nqsd0c76g0\\app\\resources\\codex.exe\" --codex-run-as-apply-patch %* 2. Sandbox log shows ACL failure on WindowsApps resources: C:\\Users\\Admin\\.codex\\.sandbox\\sandbox.log Relevant entries: - granting read ACE to E:\\WindowsApps\\OpenAI.Codex_26.305.950.0_x64__2p2nqsd0c76g0\\app\\resources for sandbox users - grant read ACE failed ... SetNamedSecurityInfoW failed: 5 - setup error: read ACL run had errors - runner: spawn failed: CreateProcessAsUserW failed: 5 3. Sandbox setup error file: C:\\Users\\Admin\\.codex\\.sandbox\\setup_error.json Content: { \"code\": \"helper_unknown_error\", \"message\": \"read ACL run had errors\" } 4. Direct execution evidence: - Running codex.exe from WindowsApps returns Access is denied. - Running codex-command-runner.exe from WindowsApps returns Access is denied. - Running the copied sandbox helper from: C:\\Users\\Admin\\.codex\\.sandbox-bin\\codex-command-runner.exe does execute, proving the copied helper is runnable while the WindowsApps executable path is not. Key conclusion: apply_patch fails because its execution path depends on launching codex.exe from the WindowsApps install location, and that launch fails with Windows error 5. This prevents apply_patch from reaching patch parsing/application at all. Request: Please investigate the Windows apply_patch launch path and packaging/ACL handling for executables under: C:\\Program Files\\WindowsApps\\OpenAI.Codex_26.305.950.0_x64__2p2nqsd0c76g0\\app\\resources In particular: - why codex.exe in WindowsApps cannot be launched for apply_patch mode - why sandbox setup fails to grant the required read ACLs - why apply_patch does not surface the real underlying error instead of only exit code 1 ### What steps can reproduce the bug? 1. Open a writable workspace, for example: E:\\Codex-test 2. Run a minimal apply_patch: *** Begin Patch *** Add File: test.md +Hello, World! *** End Patch 3. Observe apply_patch failure with exit code 1. 4. Repeat with an existing file update: *** Begin Patch *** Update File: write_probe.txt @@ -probe +patched *** End Patch 5. Observe the same failure. ### What is the expected behavior? apply_patch should successfully apply a valid patch, or at minimum return the actual underlying error. ### Additional information Related issues (possibly related, but not duplicates): - #13887 \"apply_patch fails everytime\" - similar surface symptom in the Codex App on Windows: `apply_patch` returns exit code 1 with little or no diagnostic output, while direct shell-based writes still work. - #13542 \"Windows: bundled rg in Codex Desktop resolves on PATH but fails with Access Denied in integrated PowerShell\" - likely related WindowsApps packaging / executable launch restrictions in the desktop app resources path. - #10090 \"`elevated_windows_sandbox` causing all agent commands to fail with `(no output)` (logs show `CreateProcessAsUserW failed: 5`)\" - similar low-level sandbox/process creation failure signature. - #10601 \"Sandbox setup error on Windows\" - likely related to Windows sandbox setup / ACL handling failures. - #13721 \"Codex App on Windows/WSL: targeted patch workflow is inconsistent, and review pane can show unstaged diffs while Git stays clean\" - related App-on-Windows patch instability, but this report isolates a more specific launch-path failure for `apply_patch`. I do not believe this is a duplicate of the issues above. This report appears narrower and more specific: `apply_patch.bat` resolves to `codex.exe --codex-run-as-apply-patch` inside the WindowsApps install location, sandbox setup fails while granting read ACLs on that resources path, and the runner then fails with `CreateProcessAsUserW failed: 5`. As a result, `apply_patch` never reaches actual patch parsing/application and only surfaces exit code 1. [sandbox.log](https://github.com/user-attachments/files/25822834/sandbox.log) [setup_error.json](https://github.com/user-attachments/files/25822852/setup_error.json)", "url": "https://github.com/openai/codex/issues/13965", "createdAt": "2026-03-08T10:23:04Z", "updatedAt": "2026-08-13T10:22:25Z", "timestamp": "2026-08-13T10:22:25Z", "metrics": { "reactions": 11, "comments": 14 }, "labels": [ "bug", "windows-os", "sandbox", "tool-calls", "app" ], "author": "EvgenyChukhnov", "state": "closed", "assignees": [] }, { "id": "github:openai/codex:issue:14105", "source": "github", "group": "coding-agent-infrastructure", "project": "openai/codex", "kind": "issue", "title": "Composer text becomes unreadable after live terminal theme switch", "text": "## Repro 1. Start Codex TUI in a terminal with a dark theme. 2. Type in the composer. 3. Switch the terminal to a light theme without restarting Codex. 4. Return focus to Codex and keep typing. ## Actual Composer input becomes nearly invisible, effectively white/light text on a white/light background. ## Expected Composer text should stay readable after a terminal theme change. ## Suspected cause The composer background is recomputed from terminal colors, but textarea text is rendered with default/inherited cell styling. After a dark -> light theme switch, stale foreground styling can remain while the background updates, leaving the input white-on-white. ## Relevant files - `codex-rs/tui/src/bottom_pane/chat_composer.rs` - `codex-rs/tui/src/bottom_pane/textarea.rs` - `codex-rs/tui/src/tui/event_stream.rs` Before switch: \"Image\" After: \"Image\" Same after dark to light switches # Evidence: - Composer background uses `user_message_style()`: - Typed text uses plain `Style::default()`: - Palette refresh only happens on `FocusGained`: - Style guide warning about white/black assumptions: ", "url": "https://github.com/openai/codex/issues/14105", "createdAt": "2026-03-09T17:51:41Z", "updatedAt": "2026-08-13T05:37:05Z", "timestamp": "2026-08-13T05:37:05Z", "metrics": { "reactions": 4, "comments": 2 }, "labels": [ "bug", "TUI" ], "author": "0xdeafbeef", "state": "open", "assignees": [] }, { "id": "github:openai/codex:issue:14824", "source": "github", "group": "coding-agent-infrastructure", "project": "openai/codex", "kind": "issue", "title": "CLI/TUI session can restart during long tool-heavy turns after repeated 'Function call output is missing for call id'", "text": "## Summary Codex repeatedly restarts or loses turn continuity during long-running sessions with many tool calls, especially while polling active `exec_command` sessions via repeated `write_stdin` calls. The visible user symptom is that the agent \"crashes after a while\", the conversation resumes with lost short-term continuity, and in some cases running command output retrieval gets aborted mid-flow. ## Environment - Codex client version: `0.114.0` - Observed on: `2026-03-16` - Host path with logs: `/home/drindt/.codex` - Active thread during the most recent reproductions: `019cf764-6fc4-7cd3-81d3-3872977ee047` ## User-visible behavior - Long-running task proceeds normally for several minutes. - Agent polls running commands repeatedly with `write_stdin`. - After a while the session appears to restart or lose continuity. - The user sees repeated interruptions and has to say `Fortsetzen.` multiple times. ## Reproduction pattern 1. Start a long-running terminal task with `exec_command`, for example: `make gcp-development-vm-tunnel-up` 2. Poll the running session repeatedly with `write_stdin`. 3. Interleave further tool calls and file edits during the same long turn. 4. After enough iterations, Codex loses continuity and the session is effectively restarted. ## Strong indicators from local logs ### Repeated internal normalization error `/home/drindt/.codex/log/codex-tui.log` shows repeated entries like: - `2026-03-16T17:45:09Z ... Function call output is missing for call id: call_8RF9wsbJahTQ8eOYUnuYLKYa` - The same message repeats many times for the same thread. - A second call id also appears later: `call_G7bB0oUZRjUNo8KOmxuv8oAU` This is visible both in `codex-tui.log` and in `logs_1.sqlite`. ### Session restart / shutdown around the same time The same log file shows session shutdown/re-init around the affected period: - `2026-03-16T17:52:41Z ... codex_core::codex::handlers: Shutting down Codex instance` - Shortly after: `2026-03-16T17:52:54Z ... Resumed rollout successfully from \"/home/drindt/.codex/sessions/2026/03/16/rollout-2026-03-16T17-04-40-019cf764-6fc4-7cd3-81d3-3872977ee047.jsonl\"` ### Related warnings seen in the same timeframe - Shell snapshot deletion warnings: `Failed to delete shell snapshot ... No such file or directory` - File watcher warning: `failed to unwatch /home/drindt/.codex/skills/.system: No watch was found` - MCP process group cleanup warnings in earlier restarts: `Failed to kill MCP process group ... No such process` These warnings may be secondary, but they cluster around the restart events. ## Concrete evidence query The following query returns the relevant thread-local events: ```sql select datetime(ts,'unixepoch','localtime'), level, target, substr(message,1,220) from logs where thread_id='019cf764-6fc4-7cd3-81d3-3872977ee047' and ts >= strftime('%s','2026-03-16 17:40:00') order by ts desc, ts_nanos desc limit 120; ``` ## Likely failure mode Codex appears to enter an inconsistent internal state where tool-call bookkeeping loses the output for one or more call ids (`Function call output is missing for call id ...`). After that, the session is eventually shut down and resumed, which looks like a crash from the user perspective. This does **not** currently look like a user-shell process crash in the target repo. It looks more like an internal Codex session/state management bug during long tool-heavy turns. ## Impact - Long debugging sessions become unreliable. - Operator trust drops because the agent appears to \"randomly crash\". - The user must manually continue the session multiple times. - Mid-flight reasoning context is partially lost even though rollout resume exists. ## Requested investigation 1. Investigate why `context_manager::normalize` repeatedly logs `Function call output is missing for call id ...`. 2. Check whether repeated `write_stdin` polling of long-running `exec_command` sessions can orphan or desynchronize tool-call bookkeeping. 3. Check whether session shutdown/resume is being triggered as a recovery path for this state. 4. Review the surrounding shell snapshot and file watcher warnings for causal relevance. ## Relevant local files - `/home/drindt/.codex/log/codex-tui.log` - `/home/drindt/.codex/logs_1.sqlite` - `/home/drindt/.codex/history.jsonl`", "url": "https://github.com/openai/codex/issues/14824", "createdAt": "2026-03-16T17:57:50Z", "updatedAt": "2026-08-13T15:16:10Z", "timestamp": "2026-08-13T15:16:10Z", "metrics": { "reactions": 0, "comments": 5 }, "labels": [ "bug", "tool-calls" ], "author": "drindt", "state": "open", "assignees": [] }, { "id": "github:openai/codex:issue:14860", "source": "github", "group": "coding-agent-infrastructure", "project": "openai/codex", "kind": "issue", "title": "Error running remote compact task", "text": "### What version of Codex CLI is running? 0.114.0 ### What subscription do you have? Pro ### Which model were you using? gpt-5.4 ### What platform is your computer? Linux 6.17.0-19-generic x86_64 x86_64 ### What terminal emulator and version are you using (if applicable)? Codex CLI in terminal ### What issue are you seeing? ## Problem: /compact fails after ~150s (30s timeout × 4 retries) with a misleading error message that obscures the real cause ## Root cause: original compact path does not set a per-request timeout; shared `reqwest` client inherits upstream defaults; reqwest sets Linux-family tcp_user_timeout to 30s ## Proposed fix: explicitly set a higher tcp_user_timeout in core/src/default_client.rs ## Suggested diff: ``` diff --git a/codex-rs/core/src/default_client.rs b/codex-rs/core/src/default_client.rs --- a/codex-rs/core/src/default_client.rs +++ b/codex-rs/core/src/default_client.rs @@ use std::sync::LazyLock; use std::sync::Mutex; use std::sync::RwLock; +use std::time::Duration; @@ pub const CODEX_INTERNAL_ORIGINATOR_OVERRIDE_ENV_VAR: &str = \"CODEX_INTERNAL_ORIGINATOR_OVERRIDE\"; pub const RESIDENCY_HEADER_NAME: &str = \"x-openai-internal-codex-residency\"; +const DEFAULT_TCP_USER_TIMEOUT: Duration = Duration::from_secs(120); @@ let mut builder = reqwest::Client::builder() .user_agent(ua) .default_headers(default_headers()); + // reqwest defaults tcp_user_timeout to 30s on Linux-family targets, which is too short + // for long-running unary requests such as remote compaction. + builder = builder.tcp_user_timeout(DEFAULT_TCP_USER_TIMEOUT); if is_sandboxed() { builder = builder.no_proxy(); } ``` ## Additional notes: - The error message `timeout waiting for child process to exit` is misleading for this path and warrants a separate cleanup - Consider making this value overridable via `config.toml` ### What steps can reproduce the bug? Platform: linux APP: Codex CLI Model: gpt-5.4 Keep using a context.. it will eventually get the error after filing to auto compact for ~150s `Error running remote compact task: timeout waiting for child process to exit`. It compacts usually a 1-3 times okay before it stops being able to compact it. ### What is the expected behavior? That the system doesn't timeout each compact attempt in 30 seconds as that is not enough time for the API to finish. ### Additional information Hire me ;) I chase bug relentlessly.", "url": "https://github.com/openai/codex/issues/14860", "createdAt": "2026-03-16T22:57:04Z", "updatedAt": "2026-08-13T02:54:29Z", "timestamp": "2026-08-13T02:54:29Z", "metrics": { "reactions": 93, "comments": 106 }, "labels": [ "bug", "context" ], "author": "Grallen", "state": "closed", "assignees": [] }, { "id": "github:openai/codex:issue:1490", "source": "github", "group": "coding-agent-infrastructure", "project": "openai/codex", "kind": "issue", "title": "How to downgrade?", "text": "Hi there This came up this morning, so I did it... \"Image\" Sorry, but how do I undo it? I preferred the version I was on, but unsure how to downgrade?", "url": "https://github.com/openai/codex/issues/1490", "timestamp": "2026-08-12T12:41:20Z", "metrics": { "reactions": 0, "comments": 3 }, "labels": [], "author": "hippyau", "assignees": [], "change": "new" }, { "id": "github:openai/codex:issue:14923", "source": "github", "group": "coding-agent-infrastructure", "project": "openai/codex", "kind": "issue", "title": "Desktop app: explicit cross-thread orchestration over existing thread/* and turn/* primitives", "text": "### What variant of Codex are you using? Codex desktop app ### What feature would you like to see? ## Summary Codex already has official thread lifecycle primitives (`thread/start`, `thread/resume`, `thread/fork`, `thread/read`, `thread/list`, `thread/archive`) plus per-turn overrides on `turn/start`. Subagents solve delegation **inside** a parent thread, but there is still no first-class, explicitly gated way for one thread/agent in the desktop app to inspect or message another existing thread. I think the missing abstraction is **cross-thread orchestration**, not just subagent orchestration. ## Problem Today, when one Codex thread needs input or work from another long-lived Codex thread, the user often becomes a manual relay: 1. Ask thread A what it needs from thread B 2. Copy that into thread B 3. Copy the answer back into thread A That works, but it breaks down once you have multiple durable workstreams (different repos, worktrees, roles, or settings). Subagents help for short-lived delegation, but they are still subordinate to one parent thread's control plane. They are not a full replacement for peer threads that are already durable, addressable, inspectable, and often tied to different projects. ## Proposed solution Add an **opt-in cross-thread orchestration capability** to the desktop app, backed by the existing thread/turn primitives. Suggested shape: * App-level setting such as `Cross-thread orchestration`, default **off** * Optional per-thread permission / confirmation before another thread can inspect or message it * Tool/UI surface for: * `list_threads` * `read_thread` * `create_thread` * `fork_thread` * `archive_thread` * `unarchive_thread` * `send_message_to_thread` * `send_message_to_thread` should support overrides that already conceptually exist in the stack: * model * reasoning effort * sandbox / approval policy * network / access mode * Clear audit trail in both the source and target thread so cross-thread actions are visible and attributable * Optional `config.toml` support in addition to the UI toggle ## Why this seems viable This does not look like a net-new orchestration backend problem. It looks more like an app/tool-surface and permissions problem: * the app server already understands thread lifecycle operations * the SDK and docs already describe thread creation/resume flows * the desktop app already has the concept of multiple durable threads/projects So the main work appears to be: 1. exposing the right primitives 2. gating them explicitly 3. making the UX legible and auditable ## Why threads should be first-class here Subagents are useful, but thread-first orchestration has different strengths: * threads are durable across time, not just spawned under one parent * threads can map cleanly to separate repos/worktrees/projects * threads are inspectable and resumable * threads can have distinct model/access/reasoning settings * peer threads are a better fit for \"agent A asks agent B\" than forcing everything into one parent thread's internal hierarchy ## Related issues * [#12462]() Feature: Inter-Agent Communication Channels for Direct Agent-to-Agent Messaging * openai/codex#13641 Expose thread/read and thread/list as MCP tools for tool-only clients * [#12047]() Multi-agent TUI overhaul: named agents, per-agent config, async orchestration & @mention messaging * Closed predecessors that point in the same direction: [#3280](), openai/codex#2604, openai/codex#4219 ## Acceptance criteria * Cross-thread orchestration is explicit, user-visible, and disabled by default * A thread can list/read other threads only when the capability is enabled * A thread can create/fork/archive/unarchive other threads through supported surfaces * A thread can send a follow-up instruction to another existing thread * Model/reasoning/access overrides can be applied intentionally when sending or creating * Cross-thread activity is visible in the UI and attributable * MCP/app-server surfaces gain parity where appropriate so orchestration is not app-only ### Additional information I think this is the right complement to subagents: subagents for internal delegation, threads for durable peer-to-peer orchestration.", "url": "https://github.com/openai/codex/issues/14923", "createdAt": "2026-03-17T11:52:52Z", "updatedAt": "2026-08-13T01:06:40Z", "timestamp": "2026-08-13T01:06:40Z", "metrics": { "reactions": 3, "comments": 16 }, "labels": [ "enhancement", "app-server" ], "author": "TimesAndPlaces", "state": "closed", "assignees": [] }, { "id": "github:openai/codex:issue:15723", "source": "github", "group": "coding-agent-infrastructure", "project": "openai/codex", "kind": "issue", "title": "Background subprocesses/subagents do not wake the calling agent on completion", "text": "### What version of Codex CLI is running? codex-cli 0.116.0 ### What subscription do you have? API Key ### Which model were you using? gpt-5.3-codex medium ### What platform is your computer? Linux 6.8.0-101-generic x86_64 x86_64 ### What terminal emulator and version are you using (if applicable)? tmux ### What issue are you seeing? Long-running background sub-processes and sub-agents do not inform the calling agent when they complete. Instead the calling agent must either: 1. Block the message thread by continuously polling for a result; or 2. Wait for the user to request an update ### What steps can reproduce the bug? In interactive mode, prompt the agent with: ``` Use `exec_command` to run the following script in a background terminal: `sleep 15; echo \"print the whale emoji\"` ``` or ``` Run a subagent in the background with the following prompt: `wait for 15 seconds then respond with the whale emoji\"` ``` In both cases, the agent spins up the sub-task, responds to the user, and then does nothing after the sub-task returns. ### What is the expected behavior? Agents should be informed when long-running sub-processes return so they can take autonomous action. ### Additional information In other agent harnesses, watcher scripts can be used to automate agent actions. An agent can run a script in the background that polls an external endpoint without blocking the main interaction loop. When the script returns, the agent is able to respond autonomously without user intervention. Codex agents cannot implement this pattern because sub-processes do not appear to queue a message for the agent.", "url": "https://github.com/openai/codex/issues/15723", "createdAt": "2026-03-25T06:00:58Z", "updatedAt": "2026-08-13T06:01:26Z", "timestamp": "2026-08-13T06:01:26Z", "metrics": { "reactions": 8, "comments": 15 }, "labels": [ "bug", "subagent" ], "author": "zoox101", "state": "open", "assignees": [] }, { "id": "github:openai/codex:issue:16004", "source": "github", "group": "coding-agent-infrastructure", "project": "openai/codex", "kind": "issue", "title": "Curated plugin startup sync leaks ~/.codex/.tmp/plugins-clone-* directories on failure", "text": "### What version of Codex CLI is running? `codex-cli 0.117.0` ### What subscription do you have? Plus ### Which model were you using? Not model-specific. This appears to happen during curated plugin startup sync before normal task work. ### What platform is your computer? Linux x86_64 ### What issue are you seeing? The new curated plugin startup sync can leave behind leaked temp repositories under: `$HOME/.codex/.tmp/plugins-clone-*` After upgrading to `0.117.0`, I started seeing multiple extra git repositories in VS Code source control. These were not part of my workspace repo. They turned out to be temp clones under `~/.codex/.tmp/`, some partially cloned, some empty, some full git repos with thousands of staged deletions/untracked files. Local evidence from `~/.codex/log/codex-tui.log`: - `2026-03-27T09:00:22.665896Z WARN codex_core::plugins::startup_sync: git sync failed for curated plugin sync; falling back to GitHub HTTP error=git clone curated plugins repo timed out after 30s: Cloning into '/home/.../.codex/.tmp/plugins-clone-LtJPVl'... fatal: early EOF` - `2026-03-27T12:43:09.973193Z WARN codex_core::plugins::startup_sync: git sync failed for curated plugin sync; falling back to GitHub HTTP error=git clone curated plugins repo timed out after 30s: Cloning into '/home/.../.codex/.tmp/plugins-clone-k0He1F'... fatal: early EOF` - `2026-03-27T12:43:41.545229Z WARN codex_core::plugins::manager: failed to sync curated plugins repo: failed to read download curated plugins archive response from https://api.github.com/repos/openai/plugins/zipball/aef533fd6ce0acf9b4850a5de33328a30731c18a: error decoding response body` On disk afterward I had a mix of leftovers: - full repos with `.git`, `README.md`, `.gitignore`, `.agents`, `plugins` - partial repos with only `.git` - empty plain dirs Example leftover paths: - `$HOME/.codex/.tmp/plugins-clone-EVIX7x` - `$HOME/.codex/.tmp/plugins-clone-JyUIh3` - `$HOME/.codex/.tmp/plugins-clone-KHGHUg` - `$HOME/.codex/.tmp/plugins-clone-LtJPVl` - `$HOME/.codex/.tmp/plugins-clone-k0He1F` Some of the full leftovers resolved to the curated plugins repo: - `origin = https://github.com/openai/plugins.git` - `HEAD = aef533fd6ce0acf9b4850a5de33328a30731c18a` ### What steps can reproduce the bug? I do not yet have a deterministic minimal repro, but the observed failure pattern is: 1. Run Codex CLI `0.117.0` 2. Curated plugin startup sync attempts to refresh the local curated marketplace under `~/.codex/.tmp/plugins` 3. The git path times out or fails partway through (`early EOF`) 4. The HTTP fallback also fails or does not complete cleanup 5. One or more `plugins-clone-*` temp dirs remain permanently under `~/.codex/.tmp/` This is likely easier to reproduce by forcing network instability or a timeout during: - `git clone https://github.com/openai/plugins.git` - or the fallback zipball download from GitHub API ### What is the expected behavior? Failed curated plugin sync attempts should not leave leaked temp dirs or temp git repos behind. Expected behavior: - temp clone/extract dirs are cleaned up on every error path - only the final active curated marketplace path remains: - `~/.codex/.tmp/plugins` - VS Code or other git-aware tools should never see `plugins-clone-*` leftovers as standalone repos ### Additional information I think the root cause is visible in source. In `codex-rs/core/src/plugins/startup_sync.rs`, `prepare_curated_repo_parent_and_temp_dir()` creates a temp dir and immediately calls: - `tempfile::Builder::new().prefix(\"plugins-clone-\").tempdir_in(parent)?` - then `clone_dir.keep()` That means the temp dir is detached from `tempfile` auto-cleanup before clone/download/activation has succeeded. Then both sync paths use that kept directory: - `sync_openai_plugins_repo_via_git()` - `sync_openai_plugins_repo_via_http()` There does not appear to be cleanup if any later step fails, for example: - `git clone` timeout / early EOF - zipball download failure - zip extraction failure - marketplace manifest validation failure - activation failure So the likely bug is: `prepare_curated_repo_parent_and_temp_dir()` promotes the temp dir to a persistent path too early, and failure paths never remove it. That matches the exact symptom on disk: - partial clone directories remain after failed `git clone` - empty directories remain after failed fallback stages - full repos can remain if later activation/validation does not complete If helpful, I can provide the exact local log lines and leftover directory shapes again, but the source path above already seems to explain the leak.", "url": "https://github.com/openai/codex/issues/16004", "createdAt": "2026-03-27T12:58:43Z", "updatedAt": "2026-08-12T15:38:41Z", "timestamp": "2026-08-12T15:38:41Z", "metrics": { "reactions": 1, "comments": 7 }, "labels": [ "bug", "skills" ], "author": "Alek2077", "state": "open", "assignees": [], "change": "updated" }, { "id": "github:openai/codex:issue:16127", "source": "github", "group": "coding-agent-infrastructure", "project": "openai/codex", "kind": "issue", "title": "yeet skill is over opinionated", "text": "### What issue are you seeing? I was surprised when this skill triggered and added a codex/ to a branch name and a [codex] tag to the PR title. These should be opt-in. I was also annoyed that the skill triggered and used git commands on a repo that I manage with jj. ### What steps can reproduce the bug? \"PR this\" ### What is the expected behavior? Respect existing conventions ### Additional information 019d3603-1aac-7d51-a36a-3676d75469f7", "url": "https://github.com/openai/codex/issues/16127", "createdAt": "2026-03-28T20:42:17Z", "updatedAt": "2026-08-12T14:36:54Z", "timestamp": "2026-08-12T14:36:54Z", "metrics": { "reactions": 36, "comments": 15 }, "labels": [ "bug", "skills" ], "author": "joshka", "state": "open", "assignees": [], "change": "updated" }, { "id": "github:openai/codex:issue:16615", "source": "github", "group": "coding-agent-infrastructure", "project": "openai/codex", "kind": "issue", "title": "Open Codex Chat in a New Window in VS Code", "text": "### What variant of Codex are you using? IDE Extension ### What feature would you like to see? Enable opening one or more Codex chat sessions in a separate window within VS Code. ### Additional information **Suggested UI options:** * Add a “+” button to the left of the existing Maximize and Close buttons. * Or add a three-dot menu with an option to open the current chat in a new window.", "url": "https://github.com/openai/codex/issues/16615", "createdAt": "2026-04-02T20:09:12Z", "updatedAt": "2026-08-13T14:46:13Z", "timestamp": "2026-08-13T14:46:13Z", "metrics": { "reactions": 15, "comments": 9 }, "labels": [ "enhancement", "extension" ], "author": "rafaself", "state": "closed", "assignees": [] }, { "id": "github:openai/codex:issue:17312", "source": "github", "group": "coding-agent-infrastructure", "project": "openai/codex", "kind": "issue", "title": "Improve subagent provider visibility", "text": "### What feature would you like to see? The Codex app currently makes provider selection and subagent provider behavior hard to control and hard to understand in the UI. I would like three related improvements: 1. Add an easy provider picker in the Codex app UI for chat threads. - This should make it possible to switch a thread from one provider to another without editing TOML. - If switching providers invalidates or reduces the usefulness of cached thread content, that is acceptable, but the UI should warn the user clearly before the switch. 2. Add a global way to choose a different provider for spawned agents. - This should be supported in `config.toml`. - Even better, it should also be exposed in the Codex app settings UI. - This is useful because it often makes sense to keep the main thread on one provider while sending subagents to a cheaper provider or a local model. 3. Fix the Codex app UI so subagents show the correct effective provider/model. - Right now the subagent UI can show the provider/model of the calling agent even when the subagent is actually running on a different provider. - This makes provider debugging much harder and creates false confidence about what is being used. ### Why this matters Provider/model routing is now a real workflow concern: - main agent on one provider - subagents on a cheaper provider - local models for some tasks - remote frontier models only where needed The app should support this explicitly instead of requiring low-level config work and log inspection. ### Concrete example I configured subagents to use Azure with `gpt-5.4-mini` while keeping the main agent on OpenAI. The authoritative child session metadata recorded: - `model_provider = \"azure\"` - `model = \"gpt-5.4-mini\"` But the spawned subagents self-reported and appeared in the UI as OpenAI / GPT-5. That indicates the effective runtime configuration and the displayed provider/model are diverging. ### Suggested behavior - Thread-level provider picker in the app UI. - Global default provider/model for subagents in config, plus an app settings surface for the same. - Subagent UI should display the effective resolved provider/model of the spawned session, not inherit the parent thread display. - If provider switching affects cache reuse or thread continuity, show an explicit warning before applying the change. ### Additional information This is partly a feature request and partly a correctness/UI bug: - feature request: easier provider selection in app/settings - correctness bug: subagent provider/model display does not match actual spawned-session metadata", "url": "https://github.com/openai/codex/issues/17312", "createdAt": "2026-04-10T07:49:25Z", "updatedAt": "2026-08-13T09:14:05Z", "timestamp": "2026-08-13T09:14:05Z", "metrics": { "reactions": 1, "comments": 5 }, "labels": [ "bug", "azure", "custom-model", "app" ], "author": "bakaburg1", "state": "open", "assignees": [] }, { "id": "github:openai/codex:issue:17316", "source": "github", "group": "coding-agent-infrastructure", "project": "openai/codex", "kind": "issue", "title": "Switching global provider hides previous sessions from the sidebar", "text": "### What feature would you like to see? Switching the global provider should not make previous chat sessions disappear from the Codex app sidebar. ### Current behavior - I create sessions with one provider. - I switch the global provider. - Older sessions no longer appear in the sidebar. ### Expected behavior Previous sessions should remain visible and accessible even after changing provider. If sessions are being filtered by provider, the UI should make that explicit and let me view sessions from other providers. ### Why this matters Changing provider is a normal workflow when testing OpenAI, Azure, or local models. It should not hide session history.", "url": "https://github.com/openai/codex/issues/17316", "createdAt": "2026-04-10T08:28:03Z", "updatedAt": "2026-08-13T04:15:39Z", "timestamp": "2026-08-13T04:15:39Z", "metrics": { "reactions": 8, "comments": 12 }, "labels": [ "enhancement", "custom-model", "app" ], "author": "bakaburg1", "state": "open", "assignees": [] }, { "id": "github:openai/codex:issue:17487", "source": "github", "group": "coding-agent-infrastructure", "project": "openai/codex", "kind": "issue", "title": "Resume replay can surface a stale assistant final message after restart from archived/removed subagent history", "text": "### What version of Codex CLI is running? codex-cli 0.120.0 ### What subscription do you have? Pro ### Which model were you using? gpt-5.4 ### What platform is your computer? Linux 6.12.0-124.47.1.el10_1.x86_64 x86_64 unknown ### What terminal emulator and version are you using (if applicable)? VSCode ### What issue are you seeing? After reopening Codex, an old assistant message kept reappearing as the visible final message for the current thread, even after I removed the obvious stale text from local session storage. I verified that: - the exact phrase was removed from `~/.codex` - the child subagent thread was archived in `~/.codex/state_5.sqlite` - the parent->child spawn edge was removed - the child rollout JSONL was moved out of `~/.codex/sessions/` - the parent rollout JSONL was edited to remove the exact stale phrase Despite that, after restarting the window, Codex still rendered that old assistant final message. This looks like replay/resume is reconstructing the stale final message from persisted history sources rather than only from the latest valid turn state. ### What steps can reproduce the bug? Thread id involved: - parent thread: `019d6838-2c9c-76c3-a02d-96a0cde9a4b7` - child subagent thread: `019d7def-2e30-7970-bf17-012e7ec95c90` What I observed locally suggests this repro shape: 1. Start a main thread. 2. Spawn one or more subagents from it. 3. Let one subagent produce a visible assistant final message. 4. Continue working in the parent thread so newer messages exist. 5. Restart/reopen Codex and resume the parent thread. 6. Observe that an older assistant final message can reappear as the visible final message for the parent thread. I also tested local cleanup after the fact: 1. Archive the child thread in `~/.codex/state_5.sqlite`. 2. Remove the corresponding row from `thread_spawn_edges`. 3. Move the child rollout JSONL out of `~/.codex/sessions/`. 4. Remove the exact stale phrase from the parent rollout JSONL. 5. Restart the client. Actual result: - the stale assistant final message can still reappear. Relevant local files during investigation: - parent rollout: `~/.codex/sessions/2026/04/07/rollout-2026-04-07T16-53-25-019d6838-2c9c-76c3-a02d-96a0cde9a4b7.jsonl` - child rollout: `~/.codex/sessions/2026/04/11/rollout-2026-04-11T22-05-20-019d7def-2e30-7970-bf17-012e7ec95c90.jsonl` ### What is the expected behavior? On resume/replay, Codex should only show the latest valid assistant state for the resumed thread. Archived or removed child-thread history should not be able to resurrect an older assistant final message in the parent thread UI. Replay should not treat stale historical `AgentMessage` / `TurnComplete.last_agent_message` / compacted history as a fresh final assistant response for the current thread. ### Additional information I inspected the latest `main` branch locally and found a likely replay path issue. Suspect areas: - `codex-rs/tui/src/chatwidget.rs` - replayed `EventMsg::AgentMessage(...)` still records markdown into `last_agent_markdown` - `on_task_complete(last_agent_message, from_replay)` still emits `Notification::AgentTurnComplete` even when `from_replay == true` - `codex-rs/rollout/src/recorder.rs` - `load_rollout_items()` and `get_rollout_history()` replay `EventMsg` and `Compacted` items as-is That combination seems capable of reviving stale final-message sources on resume. A plausible fix direction: 1. Do not emit `AgentTurnComplete` notifications during replay. 2. Restrict replay so only the latest valid turn contributes final-message state. 3. Add a regression test covering: - parent thread - spawned child thread - archived/removed child - replay with legacy `AgentMessage` - `TurnComplete.last_agent_message` - compacted history", "url": "https://github.com/openai/codex/issues/17487", "createdAt": "2026-04-11T19:27:42Z", "updatedAt": "2026-08-12T13:54:02Z", "timestamp": "2026-08-12T13:54:02Z", "metrics": { "reactions": 0, "comments": 3 }, "labels": [ "bug", "subagent" ], "author": "nos1609", "state": "open", "assignees": [], "change": "updated" }, { "id": "github:openai/codex:issue:17490", "source": "github", "group": "coding-agent-infrastructure", "project": "openai/codex", "kind": "issue", "title": "Memories enabled but no stage-1 outputs generated because imported threads keep has_user_event=0", "text": "## Summary With `features.memories = true`, Codex appears to have session/thread data available, but the memory startup pipeline never produces any stage-1 outputs or filesystem memory artifacts. In the affected setup: - memory feature is enabled - thread/session rows exist in the state DB - `first_user_message` is populated for CLI threads - `memory_mode` is `enabled` - but `has_user_event` remains `0` for all inspected threads As a result, no threads appear eligible for memory extraction, and the memory pipeline never produces outputs. ## Environment - Codex CLI version: `0.115.0` - Platform: macOS arm64 - Session source: primarily `cli` ## Observed behavior ### Config `~/.codex/config.toml` contains: ```toml [features] memories = true ``` ### DB state The local state DB contains thread records, but memory artifacts are not being generated: - `stage1_outputs` count = `0` - `jobs` count = `0` - `~/.codex/memories/` remains empty The `threads` table shows: - `source = 'cli'` - `memory_mode = 'enabled'` - `first_user_message` is populated - `has_user_event = 0` Example query pattern: ```sql select id, source, has_user_event, archived, memory_mode, first_user_message from threads order by updated_at desc limit 10; ``` In the affected case, `first_user_message` is populated, but `has_user_event` is still `0` for all inspected CLI threads. This also means there are zero eligible rows for a query like: ```sql select count(*) from threads where source='cli' and has_user_event=1 and archived=0 and memory_mode='enabled'; ``` which returns: ```text 0 ``` ## Why this looks wrong The thread records clearly have user-originated content (`first_user_message` is non-empty), but they do not seem to be marked as having a user event. If memory startup eligibility depends on `has_user_event`, this would prevent stage-1 extraction from ever running on otherwise valid threads. ## What I tried - confirmed `features.memories = true` - started fresh non-ephemeral root sessions - confirmed threads are present in the DB - confirmed memory mode is enabled on those threads - observed no `jobs` rows and no `stage1_outputs` ## Expected behavior If a non-ephemeral root CLI session has a real user prompt and `memory_mode='enabled'`, I would expect it to become eligible for the startup memory pipeline and eventually produce stage-1 outputs and memory artifacts. ## Actual behavior The memory pipeline appears inert because threads with real user prompts still have `has_user_event = 0`, leaving no eligible threads and no generated memory outputs. ## Possible root cause A thread import / rollout backfill / session persistence path may be failing to set `threads.has_user_event = 1` for CLI sessions, even when `first_user_message` is present.", "url": "https://github.com/openai/codex/issues/17490", "createdAt": "2026-04-11T19:46:12Z", "updatedAt": "2026-08-13T02:36:59Z", "timestamp": "2026-08-13T02:36:59Z", "metrics": { "reactions": 0, "comments": 1 }, "labels": [ "bug", "agent", "memory" ], "author": "ucalyptus", "state": "open", "assignees": [] }, { "id": "github:openai/codex:issue:18863", "source": "github", "group": "coding-agent-infrastructure", "project": "openai/codex", "kind": "issue", "title": "Plugin cache install silently drops symlinks from local plugin sources", "text": "### What issue are you seeing? ## Summary Local plugin installation into the Codex plugin cache silently drops symlinks. This breaks plugin source trees that contain valid symlinked entries. In my case, a local plugin with a Python virtual environment was copied into: ```text ~/.codex/plugins/cache/local-personal/linux-computer-use/... ``` but the cached `.venv` was missing `.venv/bin/python`, because that entry is a symlink in a normal Python venv. The cached tree still contained regular files such as `pip`, so the result looked like a partially copied venv rather than a clean missing-runtime error. This does not appear to be caused by Linux archive extraction or unpacking. The affected marketplace source is a local plugin source, and the Codex source path for local plugins does not go through tar, zip, or archive materialization. Observed failure: ```text missing venv .../.venv/bin/python ``` Local evidence from the cached plugin tree: - source plugin tree contains symlinks - cached plugin tree contains zero corresponding symlinks - `.venv/bin/python*` symlinks are missing from the cache - regular files such as `.venv/bin/pip` remain in the cache - cached venv metadata/entrypoints can still refer to the original source plugin path, which suggests a partially copied runtime rather than a rebuilt one The direct source-level cause appears to be `codex-rs/core-plugins/src/store.rs`: `copy_dir_recursive()` handles only directories and regular files and has no `is_symlink()` branch, so symlinks are silently skipped. ### What steps can reproduce the bug? A minimal repro is a local marketplace plugin whose source tree contains a symlink. 1. Create or use a local plugin source with a symlinked file: ```bash mkdir -p /tmp/codex-local-plugin/.codex-plugin printf '{\"name\":\"sample-plugin\",\"version\":\"local\",\"description\":\"sample\"}\\n' \\ > /tmp/codex-local-plugin/.codex-plugin/plugin.json echo \"hello\" > /tmp/codex-local-plugin/target.txt ln -s target.txt /tmp/codex-local-plugin/target-link.txt ``` 2. Install that plugin through a local marketplace source. 3. Inspect the installed cache entry under: ```text ~/.codex/plugins/cache//// ``` 4. Check whether the symlink was preserved: ```bash test -L ~/.codex/plugins/cache////target-link.txt ``` Actual result: the symlink is missing. Expected result: `target-link.txt` should still be a symlink pointing to `target.txt`. For local marketplace plugins, this is not an archive extraction issue: - `MarketplacePluginSource::Local` is resolved as a local path. - `materialize_marketplace_plugin_source()` returns local plugin paths directly. - The cache write is performed by `PluginStore` in `codex-rs/core-plugins/src/store.rs`. ### What is the expected behavior? Plugin cache installation should preserve symlinked files and symlinked directories from the materialized plugin source tree. If Codex intentionally does not support some filesystem entry type, the install should fail with an explicit error rather than silently omitting entries. ### Additional information I searched existing issues for `symlink plugin cache`, `plugin cache`, `local plugin symlink`, and `copy_dir_recursive`, and did not find a duplicate for this specific cache-copy behavior. The relevant code appears to be: ```rust codex-rs/core-plugins/src/store.rs ``` `copy_dir_recursive()` currently handles only directories and regular files: ```rust if file_type.is_dir() { ... } else if file_type.is_file() { fs::copy(...)?; } ``` There is already a symlink-preserving copy implementation elsewhere in the repository: ```text codex-rs/exec-server/src/local_file_system.rs ``` That implementation reads the link target and recreates the symlink, which seems like the expected behavior for plugin cache materialization as well. A possible fix would be to: - add an `is_symlink()` branch in `copy_dir_recursive()` - use `fs::read_link()` and recreate the symlink in the staged cache directory - on Unix, use `std::os::unix::fs::symlink` - on Windows, choose `symlink_dir` vs `symlink_file` - return an explicit error for unsupported entry types instead of silently skipping them I validated this approach locally with regression coverage for: - preserving a symlinked file during plugin cache install - preserving a symlinked directory during plugin cache install - preserving symlinks through the local marketplace `PluginsManager::install_plugin()` path These passed locally: ```bash cargo test --manifest-path codex-rs/Cargo.toml -p codex-core-plugins cargo test --manifest-path codex-rs/Cargo.toml -p codex-core install_plugin_supports_git_subdir_marketplace_sources cargo test --manifest-path codex-rs/Cargo.toml -p codex-core install_plugin_preserves_symlinks_from_local_marketplace_sources ```", "url": "https://github.com/openai/codex/issues/18863", "createdAt": "2026-04-21T17:12:42Z", "updatedAt": "2026-08-13T10:37:01Z", "timestamp": "2026-08-13T10:37:01Z", "metrics": { "reactions": 3, "comments": 1 }, "labels": [ "bug", "skills" ], "author": "kkkzbh", "state": "open", "assignees": [] }, { "id": "github:openai/codex:issue:18906", "source": "github", "group": "coding-agent-infrastructure", "project": "openai/codex", "kind": "issue", "title": "TUI: support Markdown math rendering for inline and block LaTeX", "text": "### What version of Codex is running? Observed in the current Codex terminal workflow. I do not have a precise version string to attach here. ### Which model were you using? Observed while using Codex in the terminal UI. ### What platform is your computer? macOS on Apple Silicon in a terminal-based Codex workflow. ### What issue are you seeing? Codex renders regular Markdown reasonably well in the terminal UI, but LaTeX math in Markdown is not rendered. In practice, inline math such as `$W = W_0 + BA$` and block math such as: ```md $$ q^T k = (q^C)^T k^C + (q^R)^T k^R $$ ``` show up as raw Markdown/LaTeX source instead of readable equations. This makes Codex less useful for: - ML and math-heavy notes - paper reading - algorithm derivations - technical documentation with equations ### What feature would you like? Support Markdown math rendering in the Codex terminal UI, ideally for both: - inline math: `$...$` - block math: `$$...$$` Possible implementation directions: - render to a terminal-friendly plain-text or Unicode pretty-printed form - add a math-aware Markdown parsing/rendering stage - optionally support KaTeX-compatible parsing before terminal rendering Even a partial first step would help: - preserve math blocks as visually distinct blocks - improve spacing/escaping for common expressions - avoid broken rendering for common LaTeX patterns ### Why this matters Codex is especially useful for coding, research, and technical writing workflows. In those workflows, mathematical notation is common. Right now the terminal UI handles prose and code, but not equations, which creates a gap for engineering and research use cases. ### Reproduction 1. Open Codex in the terminal UI. 2. Ask it to write or display Markdown containing inline and block LaTeX math. 3. Observe that the expressions are not rendered as readable equations. ### Expected behavior Math expressions should display in a readable rendered form, or at minimum in a terminal-friendly normalized representation that is much easier to read than raw LaTeX source. ### Additional context This request is specifically about the terminal / TUI rendering path, not browser-based Markdown renderers.", "url": "https://github.com/openai/codex/issues/18906", "createdAt": "2026-04-21T23:44:32Z", "updatedAt": "2026-08-13T12:35:51Z", "timestamp": "2026-08-13T12:35:51Z", "metrics": { "reactions": 22, "comments": 14 }, "labels": [ "enhancement", "TUI" ], "author": "water2078", "state": "open", "assignees": [] }, { "id": "github:openai/codex:issue:18942", "source": "github", "group": "coding-agent-infrastructure", "project": "openai/codex", "kind": "issue", "title": "Input box remain dark after the system theme turn to light", "text": "### What version of Codex CLI is running? 0.122.0 ### What subscription do you have? plus ### Which model were you using? gpt-5.4 ### What platform is your computer? Darwin 25.3.0 arm64 arm ### What terminal emulator and version are you using (if applicable)? Ghostty + Tmux ### What issue are you seeing? After the system switch to light theme in another day morning, the input box of the codex cli is still in dark mode(last night is in dark mode). I have to /exit codex and reopen it again, the input box turns to light theme. ### What steps can reproduce the bug? 1. Switch to dark mode in mac, and open codex: \"Image\" 2. then switch to light mode, and you will see the input box stay dark: \"Image\" ### What is the expected behavior? _No response_ ### Additional information _No response_", "url": "https://github.com/openai/codex/issues/18942", "createdAt": "2026-04-22T03:07:29Z", "updatedAt": "2026-08-13T12:04:40Z", "timestamp": "2026-08-13T12:04:40Z", "metrics": { "reactions": 2, "comments": 6 }, "labels": [ "bug", "TUI" ], "author": "cynicalight", "state": "open", "assignees": [] }, { "id": "github:openai/codex:issue:19943", "source": "github", "group": "coding-agent-infrastructure", "project": "openai/codex", "kind": "issue", "title": "[BUG] Undo/redo often fails in native Windows environment when apply_patch edits are tracked as full-file rewrites", "text": "### What version of the Codex App are you using (From “About Codex” dialog)? codex 26.422.30944 ### What subscription do you have? GPT pro (with GPT 5.4) ### What platform is your computer? Microsoft Windows NT 10.0.19045.0 x64 ### What issue are you seeing? On the Codex Windows app running in the native Windows environment, `undo` / `redo` is unreliable and often fails after file edits made via `apply_patch`. The problem appears related to how the app records file changes. In some cases, an edit that should be tracked as a simple append is instead recorded as a full-file replacement. Example of an append patch: (reported by gpt after apply_patch) ```patch *** Begin Patch *** Update File: hellohello.txt @@ hello line2 line3 +line4 +line5 *** End Patch ``` **Expected diff shape after this patch is `-0 +2`, but Codex sometimes shows it as `-3 +5`, as if the entire previous file was deleted and rewritten. When this happens, `undo` / `redo` fails at a very high rate.** There is a similar inconsistency with smaller edits such as( reported by gpt after apply_patch): ```patch *** Begin Patch *** Update File: hellohello.txt @@ hello +line2 +line3 *** End Patch ``` After this patch, Codex sometimes shows `-1 +3`, and sometimes `-0 +2`. In the `-0 +2` case, `undo` / `redo` usually works normally. In the `-1 +3` case, it is much more likely to fail. The same workflows behave much more normally in WSL. Since Codex appears to rely on system Git for file change tracking, this may be related to differences in Git behavior on native Windows versus WSL. ### What steps can reproduce the bug? 1. Run Codex in the native Windows environment, not WSL. 2. Tell Codex to create a file such as `hello.txt` with initial content: ```txt hello ``` 3. Tell Codex to append several lines to the file. 4. Check how Codex displays the resulting diff for the file. 5. Try using `undo` and `redo`. Observed behavior: - Sometimes the diff is shown as a normal append like `-0 +2`. - Sometimes the same kind of change is shown as delete-and-rewrite, such as `-3 +5` or `-1 +3`. - When the change is recorded as delete-and-rewrite, `undo` / `redo` frequently fails. Control comparison: 1. Repeat the same workflow in WSL. 2. The diff and `undo` / `redo` behavior are much more stable there. ### What is the expected behavior? `apply_patch` appends should be tracked as minimal line additions when the surrounding file content is unchanged. For example, this patch: ```patch *** Begin Patch *** Update File: hellohello.txt @@ hello line2 line3 +line4 +line5 *** End Patch ``` should be represented as `-0 +2`, not as a full-file rewrite like `-3 +5`. `Undo` and `redo` should work reliably after these edits in the native Windows environment, with behavior matching WSL. ### Additional information _No response_", "url": "https://github.com/openai/codex/issues/19943", "createdAt": "2026-04-28T07:02:07Z", "updatedAt": "2026-08-13T09:29:53Z", "timestamp": "2026-08-13T09:29:53Z", "metrics": { "reactions": 0, "comments": 2 }, "labels": [ "bug", "windows-os", "tool-calls", "app" ], "author": "Alkacid", "state": "open", "assignees": [] }, { "id": "github:openai/codex:issue:20214", "source": "github", "group": "coding-agent-infrastructure", "project": "openai/codex", "kind": "issue", "title": "Codex App frequently freezes/stutters on Windows 11 Pro despite sufficient system resources", "text": "### What version of the Codex App are you using (From “About Codex” dialog)? Latest Codex App downloaded from the Microsoft Store. ### What subscription do you have? Plus ### What platform is your computer? Windows 11 Pro, x64 CPU: AMD Ryzen 5 5600 RAM: 32 GB ### What issue are you seeing? I frequently experience Codex App freezes, stutters, or severe UI lag on Windows 11 Pro. This happens during normal usage, especially when: running prompts; opening existing/new chat sessions; switching into a conversation that has previous context. The app may become temporarily unresponsive or noticeably slow. This is not a full system freeze — the rest of Windows remains responsive. I checked Windows Task Manager while this happens, and system memory is not close to being fully used. My machine has 32 GB RAM and a Ryzen 5 5600 CPU, so this does not appear to be caused by insufficient hardware resources. Because this is a local desktop app running on a fairly capable machine, I would not expect frequent UI freezes during basic prompt execution or when opening chat records. This seems more likely to be a Codex App performance or optimization issue on Windows. ### What steps can reproduce the bug? Open the Codex App on Windows 11 Pro. Open an existing chat session, especially one with previous context. Run a prompt or continue the conversation. Alternatively, open a new chat record/session. The Codex App frequently becomes slow, freezes briefly, or shows heavy UI lag. This does not happen every single time, but it happens often enough to interrupt normal development work. ### What is the expected behavior? The Codex App should remain responsive while opening chats, running prompts, and switching between sessions. Even if a prompt is being processed or the context window is large, the UI should not frequently freeze or become heavily laggy on a Windows 11 Pro machine with 32 GB RAM and a Ryzen 5 5600 CPU. ### Additional information This issue occurs even when Windows Task Manager shows that RAM is not fully used. Other applications remain responsive, so the bottleneck appears to be inside the Codex App rather than the whole system. I am using the latest Codex App version available from the Microsoft Store. My hardware should be more than sufficient for normal local app usage, so I believe this may be a Windows performance/optimization issue in the Codex App.", "url": "https://github.com/openai/codex/issues/20214", "createdAt": "2026-04-29T14:27:53Z", "updatedAt": "2026-08-12T20:30:53Z", "timestamp": "2026-08-12T20:30:53Z", "metrics": { "reactions": 82, "comments": 97 }, "labels": [ "bug", "windows-os", "app", "performance" ], "author": "squarepots", "state": "open", "assignees": [] }, { "id": "github:openai/codex:issue:20668", "source": "github", "group": "coding-agent-infrastructure", "project": "openai/codex", "kind": "issue", "title": "Codex Desktop dictation fails in API-key auth mode because /backend-api/transcribe rejects API keys", "text": "### What version of the Codex App are you using (From \"About Codex\" dialog)? Version 26.429.30905 ### What subscription do you have? API key auth mode. ChatGPT login is not available for this account/device because phone verification cannot be completed. ### What platform is your computer? macOS / Darwin arm64 ### What issue are you seeing? Codex Desktop dictation fails when the app is authenticated with an OpenAI API key instead of a ChatGPT session. The user-facing error is the generic popup: ```text Unable to transcribe audio ``` This does not appear to be a microphone, input-volume, or network problem. The same machine can transcribe audio successfully through the public OpenAI audio transcription API using the configured API key. ### Steps to reproduce 1. Configure Codex Desktop to use API key auth. 2. Do not log in with ChatGPT session auth. 3. Open Codex Desktop on macOS. 4. Use dictation. 5. Dictation records audio but fails at transcription with `Unable to transcribe audio`. ### Observed behavior Local investigation showed that Codex Desktop posts dictation audio to the ChatGPT backend transcription route: ```text https://chatgpt.com/backend-api/transcribe ``` When that route is called using the configured OpenAI API key as bearer auth, the backend returns: ```json { \"error\": { \"message\": \"Unauthorized - Invalid access token\", \"code\": \"unauthorized_unknown\" }, \"status\": 401 } ``` The desktop UI collapses this into `Unable to transcribe audio`. ### Expected behavior Dictation should work for Codex Desktop users authenticated with API keys. ChatGPT login should not be required for basic dictation if the configured API key can already call OpenAI transcription APIs. ### Additional diagnostic evidence * macOS microphone permission for Codex was reset and re-granted. * Input volume was raised. * Microsoft Teams was fully quit to avoid microphone contention. * Direct network access to OpenAI APIs works. * Direct transcription against the public OpenAI audio transcription API succeeds with the same configured API key and `gpt-4o-mini-transcribe`. * A local workaround proxy was tested and confirmed working: * Codex Desktop sends its existing `/transcribe` multipart request to a local proxy. * The proxy injects `model=gpt-4o-mini-transcribe`. * The proxy forwards the request to `https://api.openai.com/v1/audio/transcriptions` using the configured API key. * Dictation works through that path. ### Suggested fix When Codex Desktop is in API-key auth mode, dictation should not send the OpenAI API key to `chatgpt.com/backend-api/transcribe` as if it were a ChatGPT backend access token. Suggested implementation options: 1. Route API-key-auth dictation directly to the public OpenAI audio transcription API (`/v1/audio/transcriptions`) and include a transcription model such as `gpt-4o-mini-transcribe`. 2. Or update the Codex/ChatGPT backend transcription route so it accepts Codex API-key auth mode correctly. ### Related issue This is related to openai/codex#18460, but this report narrows the likely root cause to API-key auth mode and includes a confirmed workaround path.", "url": "https://github.com/openai/codex/issues/20668", "createdAt": "2026-05-01T19:11:19Z", "updatedAt": "2026-08-13T09:02:09Z", "timestamp": "2026-08-13T09:02:09Z", "metrics": { "reactions": 8, "comments": 1 }, "labels": [ "bug", "auth", "app" ], "author": "someshfengade", "state": "open", "assignees": [] }, { "id": "github:openai/codex:issue:20785", "source": "github", "group": "coding-agent-infrastructure", "project": "openai/codex", "kind": "issue", "title": "Browser Use cannot upload files because file chooser / setInputFiles is not exposed in Codex Desktop IAB", "text": "### What variant of Codex are you using? App (Desktop) ### What happened? Codex Desktop Browser Use can inspect real `` controls in the in-app browser, but it cannot attach local files to them. In a Drupal content form, Browser Use could see three file inputs: - `files[field_image_hero_0][]`, `accept=\"image/*\"` - `files[field_image_title_card_0][]`, `accept=\"image/*\"` - `files[field_image_portrait_0]`, `accept=\"image/*\"` The site rendered the expected upload controls and file constraints, but Browser Use could not upload files. ### Expected behavior Browser Use should support file upload automation for real file inputs, equivalent to upstream Playwright's `locator.setInputFiles(...)`. ### Actual behavior The Codex Browser Use `PlaywrightLocator` runtime does not expose `setInputFiles`. A live capability check returned: ```js typeof tab.playwright.locator(\"input[type=file]\").setInputFiles // \"undefined\" ``` The bundled Browser Use skill documents a limited Playwright subset, and `setInputFiles` is not listed in the exposed locator API. ### Why this matters This blocks realistic browser QA and smoke testing for common workflows such as: - CMS image/file upload fields - media library forms - attachment workflows - any app that requires local file selection before save/submit The workaround is manual handoff to the native file picker, which prevents fully automated validation. ### Notes This appears Codex-specific, not a general Playwright limitation. Upstream Playwright supports file uploads through `locator.setInputFiles()` for ``. Related but not duplicate: - #20642: external/detachable Browser Use support", "url": "https://github.com/openai/codex/issues/20785", "createdAt": "2026-05-02T13:04:37Z", "updatedAt": "2026-08-13T01:08:55Z", "timestamp": "2026-08-13T01:08:55Z", "metrics": { "reactions": 0, "comments": 5 }, "labels": [ "enhancement", "tool-calls", "app", "browser" ], "author": "scottfalconer", "state": "open", "assignees": [] }, { "id": "github:openai/codex:issue:20851", "source": "github", "group": "coding-agent-infrastructure", "project": "openai/codex", "kind": "issue", "title": "Feature request: first-class Computer Use support from the Codex CLI", "text": "### Problem Computer Use is currently exposed as a Codex desktop/app plugin, but it is not presented as a first-class, supported CLI capability. The local implementation appears to be a bundled MCP helper: ```text computer-use -> ./Codex Computer Use.app/Contents/SharedSupport/SkyComputerUseClient.app/Contents/MacOS/SkyComputerUseClient mcp ``` On my machine, `codex mcp list` shows the `computer-use` server enabled from the OpenAI-bundled plugin cache, and the plugin metadata describes it as controlling Mac apps through screenshots/accessibility with user approval. The Codex CLI itself has general `mcp` commands, but `codex --help` does not expose a clear supported Computer Use workflow, permission setup, diagnostic path, or Desktop-bridge path for CLI sessions. This is related to the narrower runtime bug in #19544, but the request here is a product/API request: make Computer Use an explicitly supported Codex CLI feature, not a Desktop-only capability that users discover indirectly through bundled MCP state. ### Why this matters For automation-heavy workflows, the CLI is where agents are launched, resumed, scripted, and supervised. If the same agent can use shell, files, web search, and MCP tools from the terminal, it should also have a clear way to use Computer Use from the terminal when the user grants the necessary macOS permissions. A CLI-first workflow would let users run tasks like: ```sh codex \"Use Computer Use to inspect Chrome and summarize the current page\" codex exec \"Use Computer Use to open Xcode, run the current project, and report failures\" ``` without needing to start the task inside the Desktop app first. ### Current local evidence Environment from a current macOS install: ```text Codex app: 26.429.30905 Codex CLI: codex-cli 0.128.0 Computer Use plugin: openai-bundled/computer-use/1.0.770 macOS: 26.2 arm64 ``` Observed wiring: ```json { \"mcpServers\": { \"computer-use\": { \"command\": \"./Codex Computer Use.app/Contents/SharedSupport/SkyComputerUseClient.app/Contents/MacOS/SkyComputerUseClient\", \"args\": [\"mcp\"], \"cwd\": \".\" } } } ``` The helper bundle identifiers are: ```text com.openai.sky.CUAService com.openai.sky.CUAService.cli ``` The helper is signed by OpenAI and has parent launch constraints, so the launch context appears to matter for CLI support and permission behavior. ### Requested behavior Please provide an official CLI path for Computer Use, including: - a documented way to enable/use Computer Use from `codex` and `codex exec` - a diagnostic command or doctor flow for app permissions, TCC state, helper launch context, and MCP availability - a clear user approval flow for terminal-launched Computer Use actions - actionable errors when the CLI is launched from an unsupported context - parity between the official CLI install path and any app-bundled CLI path Possible shapes: ```sh codex computer-use doctor codex computer-use allow \"Google Chrome\" codex --enable computer-use \"Inspect Safari and summarize the page\" codex exec --enable computer-use \"List running apps and stop\" ``` The exact command shape is less important than having a supported, documented contract. ### Security requirements Computer Use from the CLI should keep the same safety posture as Desktop: - explicit per-app or per-session permissioning - visible action approval for sensitive clicks/typing - auditability of screenshots, clicks, typing, and app targets - no silent escalation from shell access to desktop control - clear behavior for non-interactive `codex exec` when approval is required ### Acceptance criteria - A fresh official Codex CLI install can use Computer Use after the required user approvals. - `codex mcp list` and the actual CLI runtime agree on whether Computer Use is usable. - A minimal CLI task can call `computer-use/list_apps` successfully. - A CLI task can inspect and act on an approved app window with the same safety prompts as Desktop. - Unsupported launch contexts fail with a clear diagnostic instead of a low-level Apple Event, code-signing, or helper-start error.", "url": "https://github.com/openai/codex/issues/20851", "createdAt": "2026-05-03T07:14:03Z", "updatedAt": "2026-08-12T17:25:11Z", "timestamp": "2026-08-12T17:25:11Z", "metrics": { "reactions": 25, "comments": 14 }, "labels": [ "enhancement", "mcp", "CLI", "computer-use" ], "author": "its-DeFine", "state": "open", "assignees": [] }, { "id": "github:openai/codex:issue:21562", "source": "github", "group": "coding-agent-infrastructure", "project": "openai/codex", "kind": "issue", "title": "Shift+Enter and Alt+Enter no longer insert newlines in Konsole", "text": "After updating to codex-cli 0.128.0, Shift+Enter and Alt+Enter no longer insert a newline in the Codex CLI prompt when running in Konsole on KDE Plasma / Arch Linux. This worked before a recent Codex update. Ctrl+J still works, but it is awkward as the only multiline input shortcut. Environment: - Codex CLI: codex-cli 0.128.0 - OS: CachyOS x86_64 - Kernel: Linux 7.0.3-1-cachyos - Shell: fish 4.7.0 - Desktop: KDE Plasma 6.6.4 - Window manager/session: KWin on Wayland - Terminal: Konsole 26.4.0 - Locale: en_US.UTF-8 Observed behavior: - Ctrl+J inserts a newline. - Shift+Enter no longer inserts a newline. - Alt+Enter no longer inserts a newline. Expected behavior: - Shift+Enter and/or Alt+Enter should insert a newline in the prompt, as before. Terminal key sequences from showkey -a: ```text Ctrl+J: ^J 10 0012 0x0a Shift+Enter: ^[OM 27 0033 0x1b 79 0117 0x4f 77 0115 0x4d Alt+Enter: ^[^M 27 0033 0x1b 13 0015 0x0d ``` It looks like Codex still handles literal LF from Ctrl+J, but may have stopped mapping the Konsole Shift+Enter / Alt+Enter escape sequences to prompt newlines.", "url": "https://github.com/openai/codex/issues/21562", "createdAt": "2026-05-07T17:19:38Z", "updatedAt": "2026-08-13T10:17:54Z", "timestamp": "2026-08-13T10:17:54Z", "metrics": { "reactions": 0, "comments": 3 }, "labels": [ "bug", "TUI", "CLI" ], "author": "bshor", "state": "closed", "assignees": [] }, { "id": "github:openai/codex:issue:21803", "source": "github", "group": "coding-agent-infrastructure", "project": "openai/codex", "kind": "issue", "title": "Feature request: Cross-device sync for Codex Projects and Chats", "text": "### What feature are you requesting? I would like Codex to support cross-device continuity for Projects and Chats when signed in with the same OpenAI account. For example, I use Codex across two Mac computers. Ideally, I could start a Codex Project or Chat on one Mac, then open Codex on another Mac with the same account and continue the same Project or Chat from where I left off. ### Why is this useful? Many developers regularly switch between a desktop and a laptop. Today, Codex sessions and project context feel tied to the local machine, which means switching devices requires manually recreating context, syncing notes, or relying on external workarounds. My ideal experience would be similar to ChatGPT conversation continuity: recent Codex Projects, Chats, task state, and high-level working context would be available across trusted devices. I understand that local filesystem paths, repositories, terminal state, and approval settings may need to remain device-specific. But it would still be very valuable to sync or restore: - Conversation history - Project metadata - Current task state - Recent working context - Associated repository information - Session summaries or checkpoints ### Possible implementation options A native account-level sync feature would be ideal. If full native sync is not currently planned, I would also be grateful for any official API, SDK, MCP integration, or supported import/export mechanism that would allow users to build this functionality themselves. For example, an official way to access, export, restore, or synchronize Codex sessions across trusted devices would make it possible to build a personal “session hub” or workflow manager around Codex. ### Related discussions / issues This request is related to, but more specifically focused on cross-device Codex continuity: - https://github.com/openai/codex/issues/5609 - https://github.com/openai/codex/discussions/14067 - https://github.com/openai/codex/issues/14722 ### Additional context Thank you for building Codex. It has been very helpful, and cross-device continuity would make it much smoother for users who regularly move between multiple computers.", "url": "https://github.com/openai/codex/issues/21803", "createdAt": "2026-05-08T19:02:12Z", "updatedAt": "2026-08-13T07:24:17Z", "timestamp": "2026-08-13T07:24:17Z", "metrics": { "reactions": 30, "comments": 3 }, "labels": [ "enhancement", "app", "session" ], "author": "HezLUO", "state": "open", "assignees": [] }, { "id": "github:openai/codex:issue:21930", "source": "github", "group": "coding-agent-infrastructure", "project": "openai/codex", "kind": "issue", "title": "PageUp/PageDown in focused composer horizontally shifts and breaks VS Code chat webview layout", "text": "### What version of the IDE extension are you using? 26.506.31421 ### What subscription do you have? plus ### Which IDE are you using? vs code ### What platform is your computer? Microsoft Windows NT 10.0.26100.0 x64 ### What issue are you seeing? When a Codex thread is open and the composer input has focus, pressing `PageUp` or `PageDown` horizontally scrolls/shifts the entire webview. After that, the Codex UI is clipped on the left, controls and content are misaligned, and a horizontal scrollbar appears at the bottom of the webview. This is unexpected because while the text input/composer is focused, `PageUp` / `PageDown` should be handled by the input/editor caret behavior. It should not scroll the surrounding webview or change the panel layout. https://github.com/user-attachments/assets/90ea6ecd-5b72-4024-b51b-417675b97ea6 \"Image\" ### What steps can reproduce the bug? 1. Open VS Code on Windows. 2. Open the Codex extension side panel / secondary side bar. 3. Open an existing Codex thread or start a new one. 4. Click into the composer input at the bottom and type some text, leaving keyboard focus in the composer. 5. Press `PageUp` or `PageDown`. Observed: the entire Codex webview shifts horizontally; content is clipped on the left and a horizontal scrollbar appears at the bottom. Expected: since the composer is focused, `PageUp` / `PageDown` should affect only the composer caret/selection behavior, not scroll or shift the surrounding webview. ### What is the expected behavior? _No response_ ### Additional information _No response_", "url": "https://github.com/openai/codex/issues/21930", "createdAt": "2026-05-09T13:10:09Z", "updatedAt": "2026-08-12T17:07:47Z", "timestamp": "2026-08-12T17:07:47Z", "metrics": { "reactions": 0, "comments": 1 }, "labels": [ "bug", "windows-os", "extension" ], "author": "alexchexes", "state": "closed", "assignees": [] }, { "id": "github:openai/codex:issue:22029", "source": "github", "group": "coding-agent-infrastructure", "project": "openai/codex", "kind": "issue", "title": "Local Secret Store for Sensitive Credentials", "text": "### What variant of Codex are you using? App ### What feature would you like to see? I would like Codex to provide a local secret management feature for sensitive information such as server usernames, passwords, API keys, SSH credentials, database passwords, and deployment tokens. In many real-world workflows, Codex may need to execute commands that require credentials. However, users may not want those credentials to be included in prompts or sent to the model server. It would be much safer if Codex allowed users to configure secrets locally and reference them by name. For example, a user could define local secrets such as: ` prod-server-username prod-server-password staging-db-password github-deploy-token ` Then, when Codex needs to run a command, the model would only see a reference such as: ` ${secrets.PROD_SERVER_PASSWORD} ` The actual secret value would only be resolved locally by the Codex runtime at execution time. The plaintext value should never be included in the prompt, model context, logs, or tool-call descriptions sent to the remote model. Suggested capabilities: A local secret store for creating, updating, deleting, and listing secret aliases. Secret references that can be used in commands, MCP tool calls, scripts, or environment variables. Runtime-only resolution, where secrets are injected locally during execution. Confirmation prompts before a secret is used, especially the first time or for high-risk operations. Project-scoped, workspace-scoped, global, and session-only secrets. Audit logs that record which secret alias was used, without recording the actual value. Redaction of secret values from terminal output, logs, conversation history, and debugging traces. Support for injecting secrets as environment variables, temporary files, stdin, or command arguments when appropriate. A clear security boundary where the model can request a secret by alias, but cannot read or print the secret value directly. The goal is to make Codex safer for real engineering, operations, deployment, database, and infrastructure workflows. Users should be able to let Codex perform authenticated local actions without exposing sensitive credentials to the model server. This would be similar in spirit to how CI systems manage secrets: the workflow can reference a secret by name, but the secret value is only resolved inside the trusted execution environment. Short Version Please consider adding a local secret management feature to Codex. Users could store sensitive credentials locally and reference them by alias. Codex would resolve those secrets only at local execution time, while the model would see only placeholder references and never receive the plaintext secret values. This would make Codex much safer for tasks involving servers, databases, deployments, private APIs, and infrastructure automation. ### Additional information _No response_", "url": "https://github.com/openai/codex/issues/22029", "createdAt": "2026-05-10T14:52:53Z", "updatedAt": "2026-08-13T16:02:09Z", "timestamp": "2026-08-13T16:02:09Z", "metrics": { "reactions": 1, "comments": 2 }, "labels": [ "enhancement", "app" ], "author": "CTOSPACE", "state": "open", "assignees": [] }, { "id": "github:openai/codex:issue:22057", "source": "github", "group": "coding-agent-infrastructure", "project": "openai/codex", "kind": "issue", "title": "Browser Use and Chrome backend time out despite installed extension and valid native host", "text": "## Summary Codex Desktop Browser Use appears unable to connect to either the in-app browser (`iab`) or the Chrome extension backend. Both paths time out at the browser-client connection/listing stage. This looks like a Browser Use/native pipe runtime issue rather than a Chrome extension installation issue. ## Environment - OS: macOS - Chrome: 147.0.7727.139 - Codex Chrome Extension: 1.1.4 - Extension ID: `hehggadaopoacecdllhhajmbjkdcmajg` - Codex Desktop app: 26.506.31421 ## What I checked Chrome side appears healthy: - Google Chrome is installed and running. - Codex Chrome Extension is installed and enabled in the Default profile. - Native Messaging Host manifest exists and points to: `/Users/timmy/.codex/plugins/cache/openai-bundled/chrome/latest/extension-host/macos/arm64/extension-host` - Manifest `allowed_origins` matches: `chrome-extension://hehggadaopoacecdllhhajmbjkdcmajg/` - The native `extension-host` process starts and opens a socket under: `/tmp/codex-browser-use/*.sock` Browser plugin side was also restored/verified: - `[plugins.\"browser-use@openai-bundled\"] enabled = true` - Browser plugin cache exists at: `/Users/timmy/.codex/plugins/cache/openai-bundled/browser-use/0.1.0-alpha2` ## Actual behavior Both browser backends fail: - `agent.browsers.list()` times out. - In-app browser (`iab`) does not become usable. - Chrome backend also times out and cannot list tabs. In Node REPL, `import.meta.__codexNativePipe` is `undefined`, even though request metadata advertises available browser backends: ```json \"x-codex-browser-use-available-backends\": [\"chrome\", \"iab\"] ``` ## Expected behavior Codex should be able to initialize Browser Use and return available browser backends via `browsers.list()`, then connect to either the in-app browser or Chrome extension backend. ## Notes This may be related to the Browser Use / Chrome extension feature being new. The symptoms suggest the extension and native host are installed correctly, but the Codex Desktop runtime is not injecting or wiring the native pipe needed by `browser-client`.", "url": "https://github.com/openai/codex/issues/22057", "createdAt": "2026-05-10T19:21:11Z", "updatedAt": "2026-08-13T07:42:42Z", "timestamp": "2026-08-13T07:42:42Z", "metrics": { "reactions": 1, "comments": 5 }, "labels": [ "bug", "app", "browser" ], "author": "Timmycosmos", "state": "open", "assignees": [] }, { "id": "github:openai/codex:issue:22779", "source": "github", "group": "coding-agent-infrastructure", "project": "openai/codex", "kind": "issue", "title": "Completed subagents continue to count against thread limit", "text": "## What version of Codex CLI is running? `codex-cli 0.130.0` ## What subscription do you have? Pro ## Which model were you using? ChatGPT 5.5 ## What platform is your computer? `Darwin 25.4.0 arm64 arm (MacBook Pro, M4 Max, MacOS Tahoe 26.4.1)` ## What terminal emulator and version are you using (if applicable)? `WarpTerminal v0.2026.05.13.09.15.stable_01` ## Codex doctor report Not available. `codex doctor --json` is not supported by this installed CLI version; it exits with `unexpected argument --json`. ## What issue are you seeing? Completed subagents can continue to count against the per-session agent thread limit. After enough subagents have completed, a later `spawn_agent` call may fail with: ```text collab spawn failed: agent thread limit reached ``` This can happen even when earlier subagents have reached a final/completed state and are no longer doing work. Explicitly closing completed agents can free the quota, which suggests the quota is tied to thread removal/close rather than completion. ## What steps can reproduce the bug? Generic reproduction: 1. Start a Codex session with subagents enabled. 2. Spawn subagents sequentially or in batches. 3. Wait for each spawned subagent to complete normally. 4. Do not explicitly close the completed subagents. 5. Continue spawning more subagents in the same session until the configured `agents.max_threads` quota is reached. Expected result: completed subagents should no longer consume active spawn quota. Actual result: later spawns can fail with `agent thread limit reached` until completed subagents are explicitly closed or the session is restarted. A focused code-level reproduction is to set a low `agents.max_threads`, spawn an agent, drive it to `TurnComplete`, and then attempt another spawn. The second spawn should be allowed once the first agent is final. ## What is the expected behavior? Subagent quota should represent agents that are currently active/running or being reused for new work, not agents that have already reached a final status. Completed agents may remain addressable for history/listing purposes, but they should not block new spawns unless they are restarted and reacquire a quota slot. ## Additional information I investigated the relevant lifecycle/accounting path and found that spawned/resumed agents increment quota, while quota release was tied to explicit shutdown/close/thread removal. Normal completion updates agent status but does not release the quota slot. I have a focused branch with a proposed fix and tests here: https://github.com/pengyou200902/codex/tree/fix/subagent-thread-limit Proposed approach: - Track counted agent IDs separately from retained agent metadata. - Release the quota slot when an agent reaches a final status, while preserving metadata. - Reacquire a quota slot before sending new work to an existing completed agent. - Handle resumed agents whose restored history already has a final status. Validation run on the branch: - `just fmt` - `just fix -p codex-core` - `cargo test -p codex-core release_spawn_slot_preserves_agent_metadata_until_thread_release` - `cargo test -p codex-core completed_agent_releases_max_threads_slot` - `cargo test -p codex-core spawn_slot` Per `docs/contributing.md`, I am opening this issue first and would only open a PR if maintainers invite one.", "url": "https://github.com/openai/codex/issues/22779", "createdAt": "2026-05-15T05:52:45Z", "updatedAt": "2026-08-13T12:52:34Z", "timestamp": "2026-08-13T12:52:34Z", "metrics": { "reactions": 0, "comments": 6 }, "labels": [ "bug", "subagent" ], "author": "pengyou200902", "state": "open", "assignees": [] }, { "id": "github:openai/codex:issue:22921", "source": "github", "group": "coding-agent-infrastructure", "project": "openai/codex", "kind": "issue", "title": "Support latex math rendering in iOS app", "text": "### What version of the Codex App are you using (From “About Codex” dialog)? ChatGPT App [1.2026.125 (25565698938)] and Codex macOS [26.513.20950 (2816)] and most updated IOS and MacOS. ### What subscription do you have? Plus ### What platform is your computer? _No response_ ### What issue are you seeing? Codex iOS doesn’t render latex math while Codex macOS does! ### What steps can reproduce the bug? Prompt codex to write latex math equations. You will see it on your mac but not on your iPhone. ### What is the expected behavior? Latex math should be rendered properly in both environments (macOS and iOS). ### Additional information _No response_", "url": "https://github.com/openai/codex/issues/22921", "createdAt": "2026-05-15T22:58:03Z", "updatedAt": "2026-08-12T16:05:32Z", "timestamp": "2026-08-12T16:05:32Z", "metrics": { "reactions": 3, "comments": 1 }, "labels": [ "enhancement", "iOS" ], "author": "AbdullahAlawad", "state": "open", "assignees": [], "change": "updated" }, { "id": "github:openai/codex:issue:23146", "source": "github", "group": "coding-agent-infrastructure", "project": "openai/codex", "kind": "issue", "title": "Codex reports Chrome extension is not installed when connected in Brave", "text": "Codex reports Chrome extension is not installed when connected in Brave # Bug report: Codex reports Chrome extension is not installed even though the extension is connected in Brave ## Summary Codex reports that the browser extension is not installed, but the Codex Chrome Extension is installed and connected in Brave. The extension-backed browser connection works from Codex, but Codex's local detection appears to check only Google Chrome stable paths and Google Chrome profile data. ## Expected behavior Codex should recognize and use the connected Codex Chrome Extension when it is installed and connected in Brave, or the error message should clearly state that the check only supports Google Chrome stable. ## Actual behavior Codex reports that the browser extension is not installed. The extension popup in Brave shows: - Status: Connected - Extension: Codex - Version: v1.1.4 The Codex extension-backed browser runtime can also communicate with the extension and enumerate open tabs. ## Environment - OS: macOS 26.4.1 (Build 25E253) - Browser in use: Brave Browser 148.1.90.122 - Default browser bundle id: `com.brave.browser` - Google Chrome stable app: not installed at `/Applications/Google Chrome.app` - Brave app: installed at `/Applications/Brave Browser.app` - Codex Chrome Extension ID: `hehggadaopoacecdllhhajmbjkdcmajg` - Codex Chrome Extension version in Brave profile: `1.1.4_0` - Codex Chrome plugin cache path observed: `chrome@openai-bundled` version `0.1.7` ## Diagnostics ### Extension-backed connection works Using the Codex Chrome plugin browser runtime: ```json { \"connection\": { \"ok\": true, \"openTabCount\": 73, \"browserType\": \"extension\" } } ``` No tab URLs are included here for privacy; the important part is that the extension connection succeeds. ### Local detector looks for Google Chrome stable The Chrome DevTools MCP check failed with: ```text Could not find Google Chrome executable for channel 'stable' at: - /Applications/Google Chrome.app/Contents/MacOS/Google Chrome. ``` ### Codex helper script outputs `scripts/chrome-is-running.js --json`: ```json { \"platform\": \"darwin\", \"running\": false, \"processes\": [] } ``` `scripts/installed-browsers.js --json`: ```json { \"platform\": \"darwin\", \"default_browser\": { \"source\": \"LaunchServices\", \"schemes\": { \"https\": { \"scheme\": \"https\", \"bundle_id\": \"com.brave.browser\", \"name\": null, \"path\": null, \"version\": null }, \"http\": { \"scheme\": \"http\", \"bundle_id\": \"com.brave.browser\", \"name\": null, \"path\": null, \"version\": null } } }, \"installed_browsers\": [] } ``` `scripts/check-extension-installed.js --json`: ```text Could not find a Chrome profile directory with Preferences in ~/Library/Application Support/Google/Chrome. ``` Exit code: `3` `scripts/check-native-host-manifest.js --json`: ```json { \"manifestPath\": \"~/Library/Application Support/Google/Chrome/NativeMessagingHosts/com.openai.codexextension.json\", \"expectedHostName\": \"com.openai.codexextension\", \"actualHostName\": \"com.openai.codexextension\", \"expectedExtensionId\": \"hehggadaopoacecdllhhajmbjkdcmajg\", \"expectedOrigin\": \"chrome-extension://hehggadaopoacecdllhhajmbjkdcmajg/\", \"allowedOrigins\": [ \"chrome-extension://hehggadaopoacecdllhhajmbjkdcmajg/\" ], \"exists\": true, \"nameMatches\": true, \"hasExpectedOrigin\": true, \"registryMatchesManifestPath\": true, \"correct\": true, \"problem\": null } ``` ## Additional local observations Brave has profile preferences at: ```text ~/Library/Application Support/BraveSoftware/Brave-Browser/Profile 1/Preferences ~/Library/Application Support/BraveSoftware/Brave-Browser/Default/Preferences ~/Library/Application Support/BraveSoftware/Brave-Browser/System Profile/Preferences ``` No Google Chrome profile preferences were found under: ```text ~/Library/Application Support/Google/Chrome ``` The Codex extension is present in the Brave default profile at: ```text ~/Library/Application Support/BraveSoftware/Brave-Browser/Default/Extensions/hehggadaopoacecdllhhajmbjkdcmajg/1.1.4_0 ``` ## Suspected cause The extension-backed runtime is able to connect to Brave, but the installation/health-check path appears to assume Google Chrome stable: - `/Applications/Google Chrome.app` - `~/Library/Application Support/Google/Chrome` Because this setup uses Brave only, the detector concludes that Chrome/the extension is missing even though the actual extension backend is connected and working. ## Suggested fix Either: 1. Support Chromium-family browsers such as Brave in the detector by checking the active connected browser/profile, or 2. If only Google Chrome stable is intended to be supported, change the user-facing error from \"extension not installed\" to a more specific message explaining that Google Chrome stable was not found or that Brave is unsupported.", "url": "https://github.com/openai/codex/issues/23146", "createdAt": "2026-05-17T12:18:14Z", "updatedAt": "2026-08-13T16:17:32Z", "timestamp": "2026-08-13T16:17:32Z", "metrics": { "reactions": 8, "comments": 4 }, "labels": [ "bug", "app", "browser" ], "author": "jarred-riggall", "state": "open", "assignees": [] }, { "id": "github:openai/codex:issue:23200", "source": "github", "group": "coding-agent-infrastructure", "project": "openai/codex", "kind": "issue", "title": "Support headless remote Linux hosts for Codex mobile without requiring the desktop app to stay online", "text": "## Summary Codex mobile is very useful as a control layer, but it is currently limited when the active Codex environment depends on a personal desktop machine staying online. Many development workflows run primarily on always-on Linux servers accessed through SSH, while the desktop app is only a local access point. It would be valuable to support a headless or remote-host mode where Codex mobile can connect to an always-on Linux host directly, without requiring the Windows desktop app to remain powered on, awake, and running. This is related to #23082, but this request is specifically about not requiring a desktop host to remain online once the real working environment is an always-on remote Linux host. ## Problem For users whose projects live on remote Linux servers, the desktop machine is not always the most reliable host for long-running Codex work. A personal workstation may be shut down, asleep, restarted, or unavailable, while the actual development servers remain online continuously. This creates friction in workflows such as: 1. Starting a long-running Codex task on a remote server. 2. Leaving the desktop machine. 3. Continuing approvals, follow-ups, checks, and reviews from mobile. 4. Keeping the task alive even if the local desktop is turned off. Today, if the desktop app is the required bridge, the user may need to keep a personal machine running only so an existing Codex conversation can continue. ## Feature request Add support for Codex mobile to connect to an always-on remote Linux host, ideally through a secure headless Codex host, daemon, or remote-host registration flow. ## Suggested design - Allow a Linux server to be registered as a Codex host. - Let the ChatGPT mobile app show registered hosts independently from desktop app availability. - Allow users to start, resume, monitor, and approve Codex work from mobile on that remote host. - Keep credentials, files, shell access, and project context on the remote host. - Clearly show the active host, project path, and permission boundary before every command approval. - Support long-running tasks even when the desktop app is offline. - Optionally allow a desktop app to remain a convenience UI, but not the only bridge. ## Security and UX safeguards - Mobile should act as a secure control and approval layer, not as a place where SSH keys or tokens are copied. - Every approval should clearly identify the remote host and project context. - Host status should be explicit: online, offline, disconnected, waiting for approval, or task running. - Admins should be able to revoke mobile access to a host. - Sensitive hostnames, usernames, IPs, and paths should not be required in the UI or issue reports. ## Expected benefit This would make Codex mobile much more useful for developers, DevOps users, infrastructure teams, and anyone whose real work happens on remote Linux environments rather than on a personal desktop machine. Suggested labels, if available: `enhancement`, `mobile`, `remote`, `ssh`, `headless`, `linux` ## Redaction check This request intentionally uses only generic examples. It does not include real hostnames, IP addresses, usernames, private repository names, internal project names, credentials, or environment-specific paths.", "url": "https://github.com/openai/codex/issues/23200", "createdAt": "2026-05-17T21:51:27Z", "updatedAt": "2026-08-12T14:10:52Z", "timestamp": "2026-08-12T14:10:52Z", "metrics": { "reactions": 48, "comments": 17 }, "labels": [ "enhancement", "iOS", "remote" ], "author": "chac4l", "state": "open", "assignees": [], "change": "updated" }, { "id": "github:openai/codex:issue:23257", "source": "github", "group": "coding-agent-infrastructure", "project": "openai/codex", "kind": "issue", "title": "Desktop compaction repeatedly embeds full image base64 in compacted checkpoints", "text": "### What version of the Codex App are you using? Codex Desktop on Windows: - App package: `OpenAI.Codex` - Version: `26.513.4821.0` - Package: `OpenAI.Codex_26.513.4821.0_x64__2p2nqsd0c76g0` One affected rollout also recorded `cli_version: 0.119.0-alpha.28`. ### What platform is your computer? Windows x64. ### What issue are you seeing? Codex Desktop context compaction appears to repeatedly persist full inline image payloads inside `compacted` checkpoints, especially under `payload.replacement_history`. This makes long image-heavy threads keep growing even after automatic compaction. It also keeps the \"background information window\" / context usage high after compaction because the new compacted checkpoint can still contain the previous screenshots as base64 data. This looks related to #18629 and #22603, but this report is focused on the compaction layer: old `compacted` checkpoints and the latest `compacted.payload.replacement_history` repeatedly contain full image payloads instead of deduplicated references, lightweight placeholders, or a single latest compacted state. ### Local evidence I inspected local saved session JSONL files under the Codex home directory. I am intentionally omitting raw session contents, local paths, screenshots, cookies, thread text, and user data. #### Affected thread A Before repair: - Rollout JSONL size: `904.9 MB` - JSONL records: `40,378` - `compacted` records: `128` - Total bytes in `compacted` records: `770.9 MB` - Lines containing `data:image`: `315` - Total bytes in lines containing `data:image`: `822.5 MB` - Total `data:image` references: `1,787` - Latest `compacted` record size: `7.66 MB` - Latest `compacted` image refs: `15` - Latest `compacted.payload.replacement_history` length: `185` - Latest `compacted` visible string chars before image removal: about `7,954,167` - Latest `compacted` contained `15` image parts, plus a copied developer/plugin instruction block and an encrypted compaction blob. After a local schema-aware cleanup that kept the latest compacted checkpoint but removed inline image payloads and old duplicate compacted checkpoints: - `compacted` records: `1` - `data:image` refs: `0` - Latest `compacted` size: about `316 KB` - Latest `replacement_history` length remained `185` - Latest visible string chars after image removal: about `264,828` This is the important signal: the useful compacted text was much smaller than the full checkpoint because prior screenshots had been embedded into `replacement_history`. #### Affected thread B Another long thread repeatedly regenerated large compacted checkpoints: - One snapshot: rollout size `430 MB` - `compacted` records: `14` - Total bytes in compacted records: `117.6 MB` - Latest compacted record: `9.02 MB` - Latest compacted image refs: `24` - The Codex UI showed the background information window still around `54%` / `139k` tokens after compaction. - Local token-count records around the same time showed a post-compaction context total around `138,789 / 258,400`. After removing old compacted records and image payloads from the latest compacted checkpoint, the same thread became much smaller and the latest compacted record was under `100 KB`. However, if the thread continued running, Codex could generate new `compacted` records that reintroduced the same image payloads. ### Why this is a product-level problem Users can manually edit JSONL as a workaround, but it is risky. During local recovery, replacing large base64-looking strings too broadly can damage fields such as `encrypted_content`, which then causes resume/reconnect failures like: ```json { \"type\": \"error\", \"error\": { \"type\": \"invalid_request_error\", \"code\": \"invalid_encrypted_content\", \"message\": \"The encrypted content [...] could not be verified. Reason: Encrypted content could not be decrypted or parsed.\" }, \"status\": 400 } ``` So the durable fix should not require users to manually mutate saved session JSONL. Codex should compact or repair these sessions in a schema-aware way. ### Steps to reproduce 1. Use Codex Desktop in a long-running thread. 2. Use image-producing workflows repeatedly, such as screenshots, browser/computer-use images, image attachments, or other tool outputs that produce `input_image` / `data:image/...;base64,...` payloads. 3. Let Codex automatically compact the context several times. 4. Inspect the saved rollout JSONL. 5. Observe many `compacted` records and a latest `compacted.payload.replacement_history` that still contains full image payloads. 6. Continue the same thread; observe that automatic compaction can create more large compacted records rather than converging to a lightweight latest summary. ### Expected behavior Context compaction should not repeatedly embed full image bytes in `compacted.payload.replacement_history`. Instead, Codex should: - store image blobs out-of-line and keep only lightweight references in replayable history - deduplicate image payloads across records and compacted checkpoints - avoid retaining old compacted checkpoints once a newer compacted checkpoint supersedes them, or keep them out of the replay/hydration path - replace old image-heavy tool outputs with schema-valid lightweight placeholders during compaction - keep `encrypted_content` opaque or remove whole reasoning records in a schema-aware way during any repair path - provide a built-in \"repair / strip old media payloads\" action for already affected sessions ### Actual behavior `compacted` checkpoints can contain full inline image base64 payloads. Old compacted checkpoints accumulate, and the latest compacted checkpoint can still contain many prior screenshots in `replacement_history`. The thread remains slow/heavy after compaction and can continue to re-grow as new compacted checkpoints are written. ### Related issues - #18629 - #22603 - #11845 ### Privacy note I am not attaching the raw rollout JSONL because it contains private prompts, local paths, screenshots, and authentication material. The report above includes only sanitized structural measurements and field/type counts.", "url": "https://github.com/openai/codex/issues/23257", "createdAt": "2026-05-18T06:52:11Z", "updatedAt": "2026-08-13T07:09:57Z", "timestamp": "2026-08-13T07:09:57Z", "metrics": { "reactions": 5, "comments": 12 }, "labels": [ "bug", "context", "app", "session", "performance" ], "author": "SimpleZion", "state": "open", "assignees": [] }, { "id": "github:openai/codex:issue:23292", "source": "github", "group": "coding-agent-infrastructure", "project": "openai/codex", "kind": "issue", "title": "Codex Desktop main thread can stay stuck thinking when a sub-agent remains active", "text": "### What version of the Codex App are you using (From “About Codex” dialog)? 26.513.31313 (2867) ### What subscription do you have? ChatGPT Pro ### What platform is your computer? ```text Darwin 25.5.0 arm64 arm ``` Hardware: Mac with Apple M1 Max. ### What issue are you seeing? Codex Desktop can leave the main thread stuck in an active `thinking` state when a sub-agent is still active/running, even after the visible work in the main thread has already completed. Observed behavior from the affected turn: - The main agent was handling a simple local configuration request: append a new section to `~/.codex/AGENTS.md`. - Because the sandbox could read but not write that home-directory file, the assistant checked the file and then checked whether the target section already existed. - The visible shell/tool work completed quickly: - `ls -l ~/.codex/AGENTS.md && tail -n 20 ~/.codex/AGENTS.md` returned successfully. - `rg -n \"Persistent Codex Agent Rules|Sub-agent Lifecycle|thread count is back to 1\" ~/.codex/AGENTS.md` returned no matches and exited normally with code 1, which is expected for `rg` when no match is found. - After that, the main thread still appeared to be stuck on `thinking` instead of completing or reporting a blocker. - The user observed that a sub-agent was still running/active, and the main thread did not clearly surface that it was waiting on that sub-agent, did not show a clear sub-agent action request, and did not automatically close/terminate the child thread. - The user had to interrupt the turn manually. After interruption, the thread showed: ```text The user interrupted the previous turn on purpose. Any running unified exec processes may still be running in the background. If any tools/commands were aborted, they may have partially executed. ``` This looks like a Desktop app sub-agent lifecycle/status synchronization problem rather than a shell command problem. The visible commands had already returned. The remaining active state appeared to be tied to a child/sub-agent thread still being considered running or not reconciled with the parent thread. Impact: - The main thread can appear hung even when its visible foreground work is done. - It is not clear to the user whether the parent is still reasoning, waiting on a sub-agent, blocked, or leaking an idle/running child thread. - The user may need to interrupt the parent turn manually, which risks leaving background work in an uncertain state. - Long-running work with sub-agents becomes harder to trust because the app does not clearly show when the thread count/lifecycle has returned to the parent-only state. ### What steps can reproduce the bug? I do not yet have a fully isolated deterministic repro, but the observed repro pattern was: 1. Open Codex Desktop on macOS using version `26.513.31313 (2867)`. 2. Use a local workspace/thread where a sub-agent has been created or is still shown as active/running. 3. In the main thread, run a simple task that should complete quickly. The observed prompt was a request to append this section to `~/.codex/AGENTS.md`: ```md # Persistent Codex Agent Rules (Sub-agent Lifecycle) You are the main orchestrator. Follow these rules on EVERY task: 1. Only spawn sub-agents when the task clearly benefits from parallelism or specialization. 2. Always assign each sub-agent a narrow, explicit role + a clear termination condition. 3. After a sub-agent completes its work (or fails), IMMEDIATELY close/terminate the sub-agent thread using an explicit close command. Do not leave any sub-agent in \"awaiting instruction\", \"running\", or idle state. 4. Before returning your final answer, confirm that ALL sub-agents have been closed and the thread count is back to 1. 5. If you ever detect a sub-agent that appears stuck, immediately stop it and report the issue. 6. Limit concurrent sub-agents to max 3-4 unless explicitly told otherwise. Use the /agent command internally when needed to inspect and manage threads. ``` 4. The main agent determines it cannot write directly to `~/.codex/AGENTS.md` from the sandbox, then runs read-only checks like: ```sh ls -l ~/.codex/AGENTS.md && tail -n 20 ~/.codex/AGENTS.md rg -n \"Persistent Codex Agent Rules|Sub-agent Lifecycle|thread count is back to 1\" ~/.codex/AGENTS.md ``` 5. The commands complete. In the observed case, `rg` returned no matches, which was expected. 6. Instead of the parent thread returning a final answer or a clear blocker, Codex Desktop continues to show the main thread as `thinking`. 7. Inspect the thread/sub-agent state. A sub-agent is still shown as active/running, but the parent thread does not clearly explain that it is waiting on that sub-agent or provide an obvious lifecycle action. 8. Interrupt the parent turn manually. Session/token/context details: - Session id was not captured from the UI at the time of the issue. - Token limit/context window usage was not captured. - No long-running shell process was visible in the transcript; the visible shell commands had completed. ### What is the expected behavior? The Desktop app should keep parent-thread and sub-agent lifecycle state synchronized. Expected behavior when a sub-agent is active: - If the parent is waiting on a sub-agent, the main thread should clearly show that state, including which sub-agent it is waiting on. - If the sub-agent is awaiting user input or review, that should be surfaced clearly in the main thread, not hidden behind a child thread state. - If the sub-agent has completed or failed, the app should reconcile that state so the parent can continue or finish. - If the sub-agent is idle/stuck, the app should provide a clear way to stop/close that sub-agent and unblock the parent. - The main thread should not remain indefinitely in a generic `thinking` state after all visible foreground tools/commands have completed. - Interrupting the parent should not leave the user uncertain about whether child agents or background work are still active. A more robust behavior would be a visible parent status such as `Waiting on sub-agent: ` or `Sub-agent requires input`, plus an explicit inspect/stop action for the child agent. ### Additional information This may be related to, but is more specific than, several existing issues: - #20754: Codex Desktop can remain stuck showing `thinking/running` even after the task has completed. - #22361: Subagent review requests are not clearly surfaced in the main thread. - #18252: Main-thread subagent list can be inconsistent or lose expand/collapse controls. The difference in this report is the macOS Desktop App version `26.513.31313 (2867)` and the specific observed failure mode where the parent thread stayed in `thinking` while a sub-agent remained active/running, even though the visible main-thread command sequence had already completed. If there is a recommended location for collecting Codex Desktop session ids, sub-agent ids, or lifecycle logs on macOS, I can attach those the next time this happens.", "url": "https://github.com/openai/codex/issues/23292", "createdAt": "2026-05-18T11:43:13Z", "updatedAt": "2026-08-12T19:05:10Z", "timestamp": "2026-08-12T19:05:10Z", "metrics": { "reactions": 2, "comments": 4 }, "labels": [ "bug", "app", "subagent" ], "author": "andrewsohrabi", "state": "open", "assignees": [] }, { "id": "github:openai/codex:issue:23418", "source": "github", "group": "coding-agent-infrastructure", "project": "openai/codex", "kind": "issue", "title": "Mobile remote-created worktree thread is not associated with project in Codex Desktop sidebar", "text": "## Summary A thread created from ChatGPT mobile through Codex remote access exists locally and can be opened by deeplink, but it does not appear in the Codex Desktop project sidebar. This looks like a project/thread association issue rather than data loss. ## Environment - Codex Desktop: 26.513.31313, build 2867 - Codex CLI: 0.131.0-alpha.9 - OS: macOS - Flow: ChatGPT mobile app -> Codex remote connection -> local Desktop host - Thread mode: worktree ## Steps to Reproduce 1. On ChatGPT mobile, connect to a local Codex Desktop host through remote access. 2. Open an existing project from that host. 3. Start a new thread in worktree mode. 4. Let the thread run normally. 5. On the Desktop app, open the same project sidebar. 6. Try to find the newly created thread. ## Expected Behavior The thread created from mobile remote access should appear in the same project sidebar on Codex Desktop. ## Actual Behavior The thread does not appear in the Desktop project sidebar. However, the thread is present in local state and can be opened directly via deeplink: ```text codex://threads/ ``` ## Local Evidence The thread exists in the local SQLite state: ```text id= archived=0 cwd=/Users//.codex/worktrees// thread_source=NULL ``` The rollout JSONL also exists locally: ```text /Users//.codex/sessions//rollout--.jsonl ``` The issue appears to be that the thread is not associated with the canonical project root: ```text /Users/// ``` In this case, the thread was created under a temporary Codex worktree path, but the Desktop sidebar did not map it back to the original project. ## Related Issues Possibly related: - https://github.com/openai/codex/issues/10522 - https://github.com/openai/codex/issues/14519 - https://github.com/openai/codex/issues/21128 - https://github.com/openai/codex/issues/20833 - https://github.com/openai/codex/issues/21581 ## Notes This is not a request for a local workaround. The expected product behavior is that threads created through mobile remote access remain visible in the corresponding Desktop project sidebar.", "url": "https://github.com/openai/codex/issues/23418", "createdAt": "2026-05-19T05:08:32Z", "updatedAt": "2026-08-13T15:34:35Z", "timestamp": "2026-08-13T15:34:35Z", "metrics": { "reactions": 3, "comments": 11 }, "labels": [ "bug", "app", "session", "remote" ], "author": "rsymon", "state": "open", "assignees": [] }, { "id": "github:openai/codex:issue:23517", "source": "github", "group": "coding-agent-infrastructure", "project": "openai/codex", "kind": "issue", "title": "request setting to disable autoscroll", "text": "### What variant of Codex are you using? App ### What feature would you like to see? I find the autoscroll during the Codex response to be visually uncomfortable - especially for longer messages. This is, I think, my preferred behavior: - a space is afforded for a short response that requires no scrolling (~10 lines) - if the output goes beyond that space, there is a small visual cue (arrow) but no autoscroll - user can scroll to see the rest of the message Please make this a setting - or even the default Stretch: - afforded space is also controllable (10 lines? 20 lines?) - afforded space (controlled by user) is interpreted by Codex as the desired length for \"typical conversational exchange\" -- longer responses are tied to specific requests by the user or are determined through context ### Additional information _No response_", "url": "https://github.com/openai/codex/issues/23517", "createdAt": "2026-05-19T18:11:43Z", "updatedAt": "2026-08-12T21:53:43Z", "timestamp": "2026-08-12T21:53:43Z", "metrics": { "reactions": 10, "comments": 5 }, "labels": [ "enhancement", "app" ], "author": "mohnjahoney", "state": "open", "assignees": [] }, { "id": "github:openai/codex:issue:23644", "source": "github", "group": "coding-agent-infrastructure", "project": "openai/codex", "kind": "issue", "title": "Codex Desktop: composer submit times out after stale conversation state accumulates; restart clears it", "text": "# Codex Desktop: composer submit times out after stale conversation state accumulates; restart clears it ## What version of the Codex App are you using? Codex Desktop `26.513.31313` on macOS arm64. ## What platform is your computer? macOS `26.4.1`, Apple Silicon. ## What issue are you seeing? After Codex Desktop had been running for about 3 days and 11 hours, existing threads started failing to submit new messages with \"Error submitting message\". Restarting Codex Desktop immediately cleared the issue. This did not look like an upstream model/API error. The affected turns had completed normally, but follow-up `turn/start` or `turn/steer` requests from the Desktop app to the local app-server/MCP path timed out after 30 seconds. At the same time, the Desktop logs showed many stale or missing conversation state errors. I am intentionally omitting full local paths, full logs, thread IDs, and Sentry event IDs from this public issue. I can provide them privately if useful. ## Observed behavior Two existing Codex Desktop threads hit the issue: - Thread A completed a turn successfully. About 30 seconds later, a queued follow-up `turn/start` timed out with `pendingCount=11`. - Thread B completed a turn successfully, then a steering turn timed out. Later attempts to submit normal follow-ups repeatedly timed out with `pendingCount` increasing from 15 to 20. Representative redacted log lines: ```text 2026-05-19T19:09:37.316Z warning [electron-message-handler] mcp_request_timeout conversationId= method=turn/start pendingCount=11 requestId= timeoutMs=30000 2026-05-19T19:09:37.353Z error [electron-message-handler] [queued-followups] Failed to send queued follow-up for conversationId= reason=Timeout 2026-05-19T19:21:30.700Z warning [electron-message-handler] mcp_request_timeout conversationId= method=turn/steer pendingCount=14 requestId= timeoutMs=30000 2026-05-19T19:21:30.771Z error [electron-message-handler] Error submitting steering turn for conversation conversationId= errorMessage=Timeout errorName=Error 2026-05-19T20:54:41.729Z warning [electron-message-handler] mcp_request_timeout conversationId= method=turn/start pendingCount=20 requestId= timeoutMs=30000 2026-05-19T20:54:41.824Z error [electron-message-handler] [Composer] submit failed cwd= errorMessage=Timeout errorName=Error followUp=local mode=local 2026-05-19T21:43:20.549Z warning [electron-message-handler] mcp_request_timeout conversationId= method=turn/start pendingCount=20 requestId= timeoutMs=30000 2026-05-19T21:43:20.669Z error [electron-message-handler] [Composer] submit failed cwd= errorMessage=Timeout errorName=Error followUp=local mode=local ``` Nearby log lines repeatedly contained errors like: ```text [electron-message-handler] Conversation state not found conversationId= [electron-message-handler] Received item/started for unknown conversation conversationId= [electron-message-handler] Received item/completed for unknown conversation conversationId= [electron-message-handler] No turns for conversation conversationId= [electron-message-handler] Item not found in turn state itemId= ``` The local Sentry/app-state snapshot around the same period showed: ```text pending_request_count=20 thread_count_active=15 thread_count_streaming_owner=6 thread_count_streaming_without_active_runtime=13 inflight_turn_count=2 thread_count_total=110 thread_count_loaded_recent=65 item_count_total_loaded=22550 max_items_in_single_turn=2892 delta_events_total≈338k delta_bytes_total_estimate≈201MB host_child_app_server_process_count=21 ``` ## Expected behavior Submitting a new message should either start a new turn or fail with a specific recoverable error. Stale conversation or streaming state should not permanently block future submits in existing threads. ## Actual behavior Composer submit and steering submit timed out after 30 seconds and continued failing until the Desktop app was restarted. ## Workaround Fully quitting and restarting Codex Desktop fixed the issue immediately. ## Suspected area This looks related to renderer/main-process conversation state, app-server request lifecycle, or stale streaming route cleanup. The repeated `unknown conversation`, `Conversation state not found`, and `streaming_without_active_runtime` signals suggest some conversation/turn routes were left in a stale state and continued to block later `turn/start` / `turn/steer` requests.", "url": "https://github.com/openai/codex/issues/23644", "createdAt": "2026-05-20T07:24:58Z", "updatedAt": "2026-08-12T23:08:28Z", "timestamp": "2026-08-12T23:08:28Z", "metrics": { "reactions": 0, "comments": 4 }, "labels": [ "bug", "app", "session", "app-server" ], "author": "JoeyTeng", "state": "open", "assignees": [] }, { "id": "github:openai/codex:issue:23807", "source": "github", "group": "coding-agent-infrastructure", "project": "openai/codex", "kind": "issue", "title": "codex-cli stalls for exactly 300s between tool result and next model request (stream disconnected)", "text": "### What version of Codex CLI is running? codex-cli 0.132.0 ### What subscription do you have? Plus ### Which model were you using? gpt-5.5 ### What platform is your computer? Microsoft Windows NT 10.0.26100.0 x64 ### What terminal emulator and version are you using (if applicable)? VS Code integrated terminal (PowerShell), codex running via openai.chatgpt VS Code extension ### Codex doctor report ```json { \"schemaVersion\": 1, \"generatedAt\": \"1779332610s since unix epoch\", \"overallStatus\": \"fail\", \"codexVersion\": \"0.132.0\", \"checks\": { \"app_server.status\": { \"id\": \"app_server.status\", \"category\": \"app-server\", \"status\": \"ok\", \"summary\": \"background server is not running\", \"details\": { \"control socket\": \"C:\\\\Users\\\\zhouj\\\\.codex\\\\app-server-control\\\\app-server-control.sock\", \"daemon state dir\": \"C:\\\\Users\\\\zhouj\\\\.codex\\\\app-server-daemon\", \"mode\": \"ephemeral\", \"pid file\": \"C:\\\\Users\\\\zhouj\\\\.codex\\\\app-server-daemon\\\\app-server.pid (missing)\", \"settings\": \"C:\\\\Users\\\\zhouj\\\\.codex\\\\app-server-daemon\\\\settings.json (missing)\", \"status\": \"not running\", \"update-loop pid file\": \"C:\\\\Users\\\\zhouj\\\\.codex\\\\app-server-daemon\\\\app-server-updater.pid (missing)\" }, \"remediation\": null, \"durationMs\": 0 }, \"auth.credentials\": { \"id\": \"auth.credentials\", \"category\": \"auth\", \"status\": \"ok\", \"summary\": \"auth is configured\", \"details\": { \"auth file\": \"C:\\\\Users\\\\zhouj\\\\.codex\\\\auth.json\", \"auth storage mode\": \"File\", \"stored API key\": \"true\", \"stored ChatGPT tokens\": \"false\", \"stored agent identity\": \"false\", \"stored auth mode\": \"api_key\" }, \"remediation\": null, \"durationMs\": 0 }, \"config.load\": { \"id\": \"config.load\", \"category\": \"config\", \"status\": \"ok\", \"summary\": \"config loaded\", \"details\": { \"CODEX_HOME\": \"C:\\\\Users\\\\zhouj\\\\.codex\", \"config.toml\": \"C:\\\\Users\\\\zhouj\\\\.codex\\\\config.toml\", \"config.toml parse\": \"ok\", \"enabled feature flags\": \"shell_tool, shell_snapshot, terminal_resize_reflow, sqlite, hooks, enable_request_compression, multi_agent, apps, tool_search, tool_suggest, plugins, plugin_hooks, in_app_browser, browser_use, browser_use_external, computer_use, plugin_sharing, image_generation, skill_mcp_dependency_install, steer, guardian_approval, goals, collaboration_modes, tool_call_mcp_elicitation, personality, fast_mode, tui_app_server, workspace_dependencies\", \"feature flag overrides\": \"goals=true\", \"feature flags enabled\": \"28\", \"log dir\": \"C:\\\\Users\\\\zhouj\\\\.codex\\\\log\", \"mcp servers\": \"0\", \"model\": \"gpt-5.5\", \"model provider\": \"custom\", \"sqlite home\": \"C:\\\\Users\\\\zhouj\\\\.codex\" }, \"remediation\": null, \"durationMs\": 0 }, \"installation\": { \"id\": \"installation\", \"category\": \"install\", \"status\": \"ok\", \"summary\": \"installation looks consistent\", \"details\": { \"PATH codex #1\": \"C:\\\\Users\\\\zhouj\\\\AppData\\\\Roaming\\\\npm\\\\codex\", \"PATH codex #2\": \"C:\\\\Users\\\\zhouj\\\\AppData\\\\Roaming\\\\npm\\\\codex.cmd\", \"PATH codex entries\": \"2\", \"current executable\": \"C:\\\\Users\\\\zhouj\\\\AppData\\\\Roaming\\\\npm\\\\node_modules\\\\@openai\\\\codex\\\\node_modules\\\\@openai\\\\codex-win32-x64\\\\vendor\\\\x86_64-pc-windows-msvc\\\\codex\\\\codex.exe\", \"install context\": \"npm\", \"managed by bun\": \"false\", \"managed by npm\": \"true\", \"managed package root\": \"C:\\\\Users\\\\zhouj\\\\AppData\\\\Roaming\\\\npm\\\\node_modules\\\\@openai\\\\codex\", \"npm update target\": \"C:\\\\Users\\\\zhouj\\\\AppData\\\\Roaming\\\\npm\\\\node_modules\\\\@openai\\\\codex\" }, \"remediation\": null, \"durationMs\": 358 }, \"mcp.config\": { \"id\": \"mcp.config\", \"category\": \"mcp\", \"status\": \"ok\", \"summary\": \"no MCP servers configured\", \"details\": {}, \"remediation\": null, \"durationMs\": 0 }, \"network.env\": { \"id\": \"network.env\", \"category\": \"network\", \"status\": \"ok\", \"summary\": \"network-related environment looks readable\", \"details\": { \"proxy env vars present\": \"NO_PROXY, no_proxy\" }, \"remediation\": null, \"durationMs\": 0 } } } ``` ### What issue are you seeing? Codex CLI periodically stalls for exactly 300 seconds (5 minutes) during a turn, showing \"Working (Xm Ys)\" with no network activity. After the 300s timeout, it logs `stream disconnected - retrying sampling request (1/5)` and resumes normally. This happens multiple times per session (5 occurrences across ~15 hours), making long-running agentic tasks unreliable. From TUI log (`~/.codex/log/codex-tui.log`): **Instance 1 — exact 300.003s gap:** 2026-05-20T12:21:44.542667Z INFO codex_core::client: close time.busy=10.9ms time.idle=40.2s *** 300 seconds of silence — no client:new, no ToolCall *** 2026-05-20T12:26:44.545840Z WARN codex_core::session::turn: stream disconnected - retrying sampling request (1/5 in 197ms)... 2026-05-20T12:26:44.746956Z INFO codex_core::client: new <- retry succeeds immediately **Instance 2 — exact 300.021s gap:** 2026-05-20T13:12:50.025022Z INFO codex_core::client: close time.busy=25.9ms time.idle=58.0s *** 300 seconds of silence *** 2026-05-20T13:17:50.046571Z WARN codex_core::session::turn: stream disconnected - retrying sampling request (1/5 in 218ms)... 2026-05-20T13:17:50.267074Z INFO codex_core::client: new <- retry succeeds immediately All 5 occurrences in this session: - 2026-05-20T12:26:44 (retry in 197ms) - 2026-05-20T13:17:50 (retry in 218ms) - 2026-05-20T15:42:53 (retry in 210ms) - 2026-05-20T15:52:04 (retry in 180ms) - 2026-05-21T00:56:48 (retry in 196ms) The retry always succeeds in under 250ms, proving the network path is healthy. The stall is entirely internal to codex_core. Additional context: - `app-server event consumer lagged; dropping ignored events skipped=93/135/231` appears in the same session - The same local proxy (127.0.0.1:15721) handles Claude Code traffic without any stalls - Average `time.idle` across all 583 requests in this session is 85s (normal model thinking time) - Large `time.idle` values up to 1262s occur during active HTTP streams WITHOUT triggering \"stream disconnected\", confirming the 300s watchdog only fires between requests ### What steps can reproduce the bug? 1. Configure codex with a custom provider endpoint: ```toml model_provider = \"custom\" model = \"gpt-5.5\" model_reasoning_effort = \"xhigh\" sandbox_mode = \"danger-full-access\" [model_providers.custom] name = \"custom\" wire_api = \"responses\" supports_websockets = false requires_openai_auth = true base_url = \"http://127.0.0.1:15721/v1\" 2. Start a codex session with a complex task that requires multiple tool calls (file reads, shell commands, code edits) 3. Let it run for 30+ minutes 4. Observe periodic 300-second gaps where no HTTP requests are sent to the model endpoint, followed by \"stream disconnected - retrying sampling request (1/5)\" Detailed sequence before first stall: 12:20:40 client: close (model returned tool_call response, time.idle=29.5s) 12:20:40 ToolCall: shell_command (read test_supervisor.py) 12:20:40 ToolCall: shell_command (read test_session_adapter.py) 12:20:40 ToolCall: shell_command (git diff) 12:21:03 client: close (model responded, time.idle=22.4s) 12:21:04 ToolCall: shell_command (Get-Content SKILL.md) <- executes in ~200ms 12:21:04 client: new <- sends tool result back to model 12:21:44 client: close time.idle=40.2s <- model responds normally *** 300 seconds of silence — no client:new, no ToolCall *** 12:26:44 stream disconnected - retrying (1/5 in 197ms) 12:26:44 client: new <- retry works instantly The model's response at 12:21:44 completes normally. After client: close, codex_core should either issue the next client: new or complete the turn. Instead, nothing happens for exactly 300 seconds. No thread ID available (custom provider endpoint). ### What is the expected behavior? After `client: close`, the turn should immediately either: 1. Dispatch the next tool call from the response, or 2. Send the next `client: new` request with tool results, or 3. Complete the turn There should be no 300-second idle gap between a successful response and the next action. The 300s value is suspiciously precise (300.003s and 300.021s), suggesting a hardcoded timeout constant in `codex_core::session::turn` that fires when the turn state machine fails to advance after receiving a complete response. ### Additional information **Analysis:** The 300-second value appears to be a hardcoded stream-activity watchdog in `codex_core::session::turn`. The pattern suggests a race condition where the turn state machine sometimes fails to advance after receiving a complete model response. It sits idle until the watchdog fires and forces a retry. **This is NOT a network issue because:** - The same local proxy handles Claude Code traffic without any stalls - The retry after 300s succeeds in <250ms every time - `time.idle` values on normal requests (22-134s) show the model endpoint is responsive **Possibly related:** - `app-server event consumer lagged; dropping ignored events skipped=93/135/231` — TUI event loop under pressure, may indicate backpressure blocking the turn from advancing - Multiple `codex_core::tools::router: error=Exit code: 1` errors in the same session (tool execution failures) - `model_reasoning_effort = \"xhigh\"` produces longer model responses and more tool calls per turn, possibly increasing the chance of hitting the race condition **Suggested investigation areas:** 1. The 300s constant in `codex_core::session::turn` — is this a stream keepalive/watchdog timer? 2. Possible race condition between the response parser completing and the turn state machine's next-step dispatch 3. Whether `app-server event consumer lagged` indicates backpressure that blocks the turn from advancing 4. Whether the `responses` wire API path has a different state machine than the `chat` path **Log grep patterns for reproduction:** ```bash grep \"stream disconnected\" ~/.codex/log/codex-tui.log grep \"client: close\\|client: new\" ~/.codex/log/codex-tui.log grep \"app-server event consumer lagged\" ~/.codex/log/codex-tui.log Session stats: Log spans: 2026-05-05 to 2026-05-21 Total client new/close pairs: 1255 Stream disconnects: 5 Average time.idle: 85s Max time.idle (without triggering disconnect): 5463s", "url": "https://github.com/openai/codex/issues/23807", "timestamp": "2026-08-12T12:38:54Z", "metrics": { "reactions": 1, "comments": 5 }, "labels": [ "bug", "windows-os", "CLI", "custom-model", "connectivity", "performance" ], "author": "dehnck", "assignees": [], "change": "new" }, { "id": "github:openai/codex:issue:23851", "source": "github", "group": "coding-agent-infrastructure", "project": "openai/codex", "kind": "issue", "title": "Desktop: thread.archived silently reset to 0 on next app cycle for any thread whose sessions/.jsonl exists", "text": "### What version of the Codex App are you using (From \"About Codex\" dialog)? 26.519.2081.0 ### What subscription do you have? Pro ### What platform is your computer? Microsoft Windows NT 10.0.26200.0 x64 (Windows native binary path; not WSL backend) ### What issue are you seeing? `threads.archived` is silently reset from `1` back to `0` (and `threads.archived_at` is cleared from a populated timestamp back to `NULL`) for any thread whose `sessions//rollout-*.jsonl` file still exists on disk, on the next Codex Desktop session-reconciliation cycle after a bulk archive performed via direct `UPDATE` on `state_5.sqlite`. This is **not** a UI display issue. The archive *flag itself* on the row is reverted by the backend. The thread reappears in the active sidebar at the next sync. `_sqlx_migrations` is unaffected; `PRAGMA integrity_check` returns `ok`; only `threads.archived` and `threads.archived_at` are mutated. ### Deterministic evidence (this is a clean repro, not a flaky one) I bulk-archived 121 threads via a single atomic transaction: ```sql BEGIN IMMEDIATE; UPDATE threads SET archived = 1, archived_at = ? -- current unix ms WHERE archived = 0 AND updated_at_ms < ?; -- now - 5 days in ms -- UPDATE affected 121 rows COMMIT; ``` Immediate post-COMMIT SELECT verified `active=62, archived=161` (was `active=183, archived=40` before). `PRAGMA integrity_check` returned `ok`. A bit-for-bit backup of `state_5.sqlite` taken right after the COMMIT also shows `archived=161`. I then closed Codex, did unrelated work for ~70 minutes during which Codex ran normally (started/stopped a few times, applied migrations, ran reconciliation), and re-queried `state_5.sqlite`: ```text archived=1 → 40 (back to pre-UPDATE baseline) archived=0 → 183 (back to pre-UPDATE baseline) archived_at IS NOT NULL → 40 (back to pre-UPDATE baseline) archived=0 AND archived_at NOT NULL → 0 (no \"flag-flipped-only\" rows) ``` The 121 archive events were **fully wiped** — both the `archived` flag AND the `archived_at` timestamp were restored. Compared file hashes between the post-archive backup and the current live `state_5.sqlite`: hashes differ (file is not a backup restore — content has otherwise advanced normally), but the archive-related fields are exactly equal to the pre-archive state for those 121 rows. ### Perfect correlation with session-file presence I extracted the set of 121 thread IDs that were targeted by my `UPDATE` (from the pre-UPDATE backup) and checked their `rollout_path` value against the actual filesystem: ```text Threads I archived (matched by ID against pre-UPDATE backup): 121 Of those — live state archived=1: 0 Of those — live state archived=0: 121 Of those — rollout_path file exists at ~/.codex/sessions/...: 121 Of those — rollout_path file missing on disk: 0 ``` **121 / 121 / 121.** Every single thread I archived had its session jsonl file still present on disk, and every single one was un-archived by the next reconciliation cycle. ### What this is NOT - **Not** a v32 `threads_preview` migration side effect. I extracted the bundled migration SQL from the binary's `.rodata` section (it lives just after the migration string at offset ~185452328 in `resources/codex.exe` for this release). The migration body is: ```sql ALTER TABLE threads ADD COLUMN preview TEXT NOT NULL DEFAULT ''; UPDATE threads SET preview = first_user_message WHERE preview = '' AND first_user_message <> ''; UPDATE threads SET preview = ( SELECT thread_goals.objective FROM thread_goals WHERE thread_goals.thread_id = threads.id ) WHERE preview = '' AND EXISTS ( SELECT 1 FROM thread_goals WHERE thread_goals.thread_id = threads.id AND thread_goals.objective <> '' ); ``` The migration only writes to `preview`. It does not touch `archived` or `archived_at`. Confirmed independently. - **Not** a SQLx CRLF/LF checksum-drift recurrence (#23777 / #23787). `_sqlx_migrations` is intact; integrity_check is ok; baseline verifier passes. - **Not** a Phase 1 / WAL-replay edge case. I confirmed the archive `COMMIT` landed in the main DB file (not just the WAL) via a post-commit `sqlite3` open after Codex was fully stopped, before any subsequent restart. - **Not** UI-only. The `archived=0` and `archived_at IS NULL` mutation is visible at the SQL level when querying `state_5.sqlite` directly. It is the backend that is performing the reversion. ### Root-cause hypothesis (testable) The Codex Desktop backend appears to run a session-reconciliation pass that iterates `~/.codex/sessions////rollout-*.jsonl` and, for any thread whose `rollout_path` matches a present file, force-sets `archived=0` and clears `archived_at` — treating \"session jsonl exists on disk\" as evidence-of-active that should override any persisted archive state. If correct, this is a **policy bug**, not a code bug per se: the policy treats session-on-disk as primary truth and discards the row's own archived state, even when that state was explicitly written by the user (or by a tool the user authorized). ### What steps can reproduce the bug? 1. Open Codex Desktop on a profile with at least ~50 threads that are >5 days old (i.e., realistic accumulated state). Confirm in the UI sidebar that they are listed as Active. 2. Close Codex Desktop completely (`Get-Process Codex,codex | Stop-Process -Force` on Windows; ensure no Codex backend processes remain). 3. Confirm `~/.codex/state_5.sqlite` is unlocked: no `-shm` / `-wal` siblings, or `-wal` is 0 bytes / empty. 4. Run a direct DB archive: ```bash sqlite3 ~/.codex/state_5.sqlite \" UPDATE threads SET archived = 1, archived_at = $(date +%s%3N) WHERE archived = 0 AND updated_at_ms < $(($(date +%s%3N) - 5*24*60*60*1000)); \" sqlite3 ~/.codex/state_5.sqlite \"PRAGMA integrity_check;\" # should print: ok sqlite3 ~/.codex/state_5.sqlite \"SELECT COUNT(*) FROM threads WHERE archived=1;\" ``` Record the post-UPDATE archived count. 5. Relaunch Codex Desktop. Let it complete startup including any backfill / reconciliation passes (give it ~2 minutes on a non-trivial session corpus). 6. Re-query `state_5.sqlite`: ```bash sqlite3 ~/.codex/state_5.sqlite \"SELECT COUNT(*) FROM threads WHERE archived=1;\" sqlite3 ~/.codex/state_5.sqlite \"SELECT COUNT(*) FROM threads WHERE archived=0 AND archived_at IS NOT NULL;\" ``` Expected (current actual behavior): archived count is back near pre-UPDATE baseline; the `archived=0 AND archived_at NOT NULL` \"smoking gun\" count is **0** (the timestamp is cleared along with the flag). ### What is the expected behavior? The user's persisted archive state should be respected. Either: **Fix A (preferred):** Treat `archived_at IS NOT NULL` as user-intent and skip the un-archive reconciliation step for those rows. Sessions can still exist on disk for legitimate reasons (history retention, search) without implying the thread should be active. **Fix B:** Reconciliation un-archives a row only when a *newly arrived* session jsonl is detected (file mtime > thread.archived_at), not on every reconciliation cycle. **Fix C:** Remove the un-archive-from-session-presence behavior entirely and rely only on explicit user action (clicking Unarchive in the UI) to flip `archived=0`. If a session file exists on disk for an archived thread, that's fine — the thread is archived; the session jsonl is historical. ### Why this matters - The archive feature is silently non-functional for users with non-trivial accumulated history. A user who relies on the archive feature to manage sidebar load will see their archives un-do themselves and re-bloat the sidebar. - For automated / scripted bulk-archive workflows (operators on multi-agent systems, IT-managed Codex profiles, profile cleanup scripts), the archive operation is structurally unreliable — there is no API or DB-level write that survives the next reconciliation cycle for any thread with retained session data. - This compounds with the GUI 30s backfill timeout issue (#23787) on profiles with large session corpora: such profiles are exactly the ones where archive is most needed, and exactly the ones where archive is silently reverted. ### Additional information #### Suggested testing on the Codex side If maintainers want to verify the hypothesis without my repro: 1. Pick any archived thread T in a test profile. 2. Confirm T's `rollout_path` file exists at `~/.codex/sessions/.../rollout-*.jsonl`. 3. Restart Codex Desktop. 4. Re-check T's `archived` value in `state_5.sqlite` post-reconciliation. If T flipped from `archived=1` to `archived=0` without any user UI interaction, the reconciliation pass is the source. #### Related issues that are not this one - #23777 (CRLF/LF SQLx migration checksum drift) — different bug; involves `_sqlx_migrations.checksum`, not `threads.archived`. - #23787 (logs_2.sqlite migrations modified in place + 30s GUI backfill cap) — different bug; backfill ≠ session-reconciliation. - #17354 (Recent thread history wiped in app, present in CLI) — opposite direction; this issue is \"history that should-be-archived is silently un-archived.\" - #19742 (Codex Desktop automation run is immediately auto-archived after start) — opposite direction; automation-specific. #### Workaround for affected users None currently survives reconciliation. Possible mitigations: - Move corresponding `~/.codex/sessions/<...>.jsonl` files out of the sessions tree before archiving (destructive to history). - Use only the UI Archive feature (which presumably handles reconciliation correctly — untested by me). - Wait for upstream fix. I would prefer not to delete session jsonl files; they are historical record. The fix belongs in the reconciliation logic, not in a user workaround. #### Reproducibility The 121/121 correlation in my data is deterministic. If maintainers want the anonymized thread-ID set + their rollout_path values for verification, I can provide.", "url": "https://github.com/openai/codex/issues/23851", "createdAt": "2026-05-21T09:34:05Z", "updatedAt": "2026-08-12T21:13:05Z", "timestamp": "2026-08-12T21:13:05Z", "metrics": { "reactions": 0, "comments": 2 }, "labels": [ "bug", "windows-os", "app", "session" ], "author": "JustinJLeopard", "state": "open", "assignees": [] }, { "id": "github:openai/codex:issue:23930", "source": "github", "group": "coding-agent-infrastructure", "project": "openai/codex", "kind": "issue", "title": "Codex app subagent cards can remain stuck/visible after close while close/readback reports no live agent", "text": "## Summary In the Codex app, completed or closed subagents can appear to remain visible/stuck in the UI for a long time even after the supported close/readback path reports that there is no live agent handle left. ## Component Codex app / Desktop on macOS. I do not know the exact app version from the UI at the time of filing. ## What happened A workflow used several subagents for bounded helper work. After the helpers completed, attempts to close them by exact returned agent IDs produced a mix of: - a completed previous status, - a running or pending previous status followed by successful disappearance from readback, - or not_found for handles that were already gone from the live route. Even after those close/readback results, the app UI could still make it look like subagents were present or stuck. In one child/subagent view, the UI showed a banner asking the parent to resume the sub-agent to continue the conversation, which suggests the child was closed, but the surrounding UI state still made it unclear whether a subagent was active, closed, or stale. ## Expected behavior After a subagent completes and is closed, the Codex app should make the lifecycle state unambiguous: - closed/completed subagent cards should update or disappear from active/open UI surfaces, - stale IDs should be shown as already closed rather than appearing stuck, - the parent thread should have a clear way to see that no live subagent remains, - and not_found after close/readback should not leave the user thinking an agent is still running or consuming an active slot. ## Actual behavior The live close/readback route can indicate that no live handle remains, while the UI still appears to show stale/open subagent state or a closed-child resume banner. This makes it hard to tell whether work is still running, whether slots are still occupied, or whether the UI is stale. ## Impact This is confusing during long-running work and makes it difficult to trust whether background/subagent work has actually stopped. It can lead to repeated close attempts and uncertainty about whether resources or subagent slots are still in use. ## Request Please clarify or fix the Codex app subagent lifecycle UI so the app reliably reflects completed/closed/stale states after subagent close/readback, especially when close returns not_found for an already-gone handle or when a child thread shows the parent-resume banner.", "url": "https://github.com/openai/codex/issues/23930", "createdAt": "2026-05-21T20:59:48Z", "updatedAt": "2026-08-13T06:21:30Z", "timestamp": "2026-08-13T06:21:30Z", "metrics": { "reactions": 4, "comments": 20 }, "labels": [ "bug", "app", "subagent" ], "author": "omarpinarecords", "state": "open", "assignees": [] }, { "id": "github:openai/codex:issue:23968", "source": "github", "group": "coding-agent-infrastructure", "project": "openai/codex", "kind": "issue", "title": "Git branch names fail to display in the statusline with these settings.", "text": "### What version of Codex CLI is running? 0.132 ### What subscription do you have? none ### Which model were you using? gpt-5.5 ### What platform is your computer? windows ### What terminal emulator and version are you using (if applicable)? powershell ### Codex doctor report ```json { \"schemaVersion\": 1, \"generatedAt\": \"1779410699s since unix epoch\", \"overallStatus\": \"fail\", \"codexVersion\": \"0.132.0\", \"checks\": { \"app_server.status\": { \"id\": \"app_server.status\", \"category\": \"app-server\", \"status\": \"ok\", \"summary\": \"background server is not running\", \"details\": { \"control socket\": \"C:\\\\Users\\\\CMJ\\\\.codex\\\\app-server-control\\\\app-server-control.sock\", \"daemon state dir\": \"C:\\\\Users\\\\CMJ\\\\.codex\\\\app-server-daemon\", \"mode\": \"ephemeral\", \"pid file\": \"C:\\\\Users\\\\CMJ\\\\.codex\\\\app-server-daemon\\\\app-server.pid (missing)\", \"settings\": \"C:\\\\Users\\\\CMJ\\\\.codex\\\\app-server-daemon\\\\settings.json (missing)\", \"status\": \"not running\", \"update-loop pid file\": \"C:\\\\Users\\\\CMJ\\\\.codex\\\\app-server-daemon\\\\app-server-updater.pid (missing)\" }, \"remediation\": null, \"durationMs\": 0 }, \"auth.credentials\": { \"id\": \"auth.credentials\", \"category\": \"auth\", \"status\": \"ok\", \"summary\": \"auth is configured\", \"details\": { \"auth file\": \"C:\\\\Users\\\\CMJ\\\\.codex\\\\auth.json\", \"auth storage mode\": \"File\", \"stored API key\": \"true\", \"stored ChatGPT tokens\": \"false\", \"stored agent identity\": \"false\", \"stored auth mode\": \"api_key\" }, \"remediation\": null, \"durationMs\": 0 }, \"config.load\": { \"id\": \"config.load\", \"category\": \"config\", \"status\": \"ok\", \"summary\": \"config loaded\", \"details\": { \"CODEX_HOME\": \"C:\\\\Users\\\\CMJ\\\\.codex\", \"config.toml\": \"C:\\\\Users\\\\CMJ\\\\.codex\\\\config.toml\", \"config.toml parse\": \"ok\", \"cwd\": \"E:\\\\Workspace\", \"enabled feature flags\": \"shell_tool, shell_snapshot, terminal_resize_reflow, sqlite, hooks, enable_request_compression, multi_agent, apps, tool_search, tool_suggest, plugins, plugin_hooks, in_app_browser, browser_use, browser_use_external, computer_use, plugin_sharing, image_generation, skill_mcp_dependency_install, steer, guardian_approval, collaboration_modes, tool_call_mcp_elicitation, personality, fast_mode, tui_app_server, workspace_dependencies\", \"feature flag overrides\": \"none\", \"feature flags enabled\": \"27\", \"log dir\": \"C:\\\\Users\\\\CMJ\\\\.codex\\\\log\", \"mcp servers\": \"1\", \"model\": \"gpt-5.5\", \"model provider\": \"OpenAI\", \"sqlite home\": \"C:\\\\Users\\\\CMJ\\\\.codex\" }, \"remediation\": null, \"durationMs\": 0 }, \"installation\": { \"id\": \"installation\", \"category\": \"install\", \"status\": \"ok\", \"summary\": \"installation looks consistent\", \"details\": { \"PATH codex #1\": \"C:\\\\Users\\\\CMJ\\\\AppData\\\\Roaming\\\\npm\\\\codex\", \"PATH codex #2\": \"C:\\\\Users\\\\CMJ\\\\AppData\\\\Roaming\\\\npm\\\\codex.cmd\", \"PATH codex entries\": \"2\", \"current executable\": \"C:\\\\Users\\\\CMJ\\\\AppData\\\\Roaming\\\\npm\\\\node_modules\\\\@openai\\\\codex\\\\node_modules\\\\@openai\\\\codex-win32-x64\\\\vendor\\\\x86_64-pc-windows-msvc\\\\codex\\\\codex.exe\", \"install context\": \"npm\", \"managed by bun\": \"false\", \"managed by npm\": \"true\", \"managed package root\": \"C:\\\\Users\\\\CMJ\\\\AppData\\\\Roaming\\\\npm\\\\node_modules\\\\@openai\\\\codex\", \"npm update target\": \"C:\\\\Users\\\\CMJ\\\\AppData\\\\Roaming\\\\npm\\\\node_modules\\\\@openai\\\\codex\" }, \"remediation\": null, \"durationMs\": 405 }, \"mcp.config\": { \"id\": \"mcp.config\", \"category\": \"mcp\", \"status\": \"ok\", \"summary\": \"MCP configuration is locally consistent\", \"details\": { \"configured servers\": \"1\", \"disabled servers\": \"0\", \"stdio servers\": \"1\" }, \"remediation\": null, \"durationMs\": 6 }, \"network.env\": { \"id\": \"network.env\", \"category\": \"network\", \"status\": \"ok\", \"summary\": \"network-related environment looks readable\", \"details\": { \"proxy env vars\": \"none\" }, \"remediation\": null, \"durationMs\": 0 }, \"network.provider_reachability\": { \"id\": \"network.provider_reachability\", \"category\": \"reachability\", \"status\": \"fail\", \"summary\": \"one or more required provider endpoints are unreachable over HTTP\", \"details\": { \"OpenAI API base URL\": \"http://192.168.3.16:3200 request timed out (required)\", \"reachability mode\": \"API key auth\" }, \"remediation\": \"Check proxy, VPN, firewall, DNS, and custom CA configuration.\", \"durationMs\": 3019 }, \"network.websocket_reachability\": { \"id\": \"network.websocket_reachability\", \"category\": \"websocket\", \"status\": \"ok\", \"summary\": \"Responses WebSocket is not enabled for the active provider\", \"details\": { \"model provider\": \"OpenAI\", \"provider name\": \"OpenAI\", \"proxy env vars\": \"none\", \"supports websockets\": \"false\", \"wire API\": \"responses\" }, \"remediation\": null, \"durationMs\": 0 }, \"runtime.provenance\": { \"id\": \"runtime.provenance\", \"category\": \"runtime\", \"status\": \"ok\", \"summary\": \"running npm on windows-x86_64\", \"details\": { \"commit\": \"unknown\", \"current executable\": \"C:\\\\Users\\\\CMJ\\\\AppData\\\\Roaming\\\\npm\\\\node_modules\\\\@openai\\\\codex\\\\node_modules\\\\@openai\\\\codex-win32-x64\\\\vendor\\\\x86_64-pc-windows-msvc\\\\codex\\\\codex.exe\", \"install method\": \"npm\", \"platform\": \"windows-x86_64\", \"version\": \"0.132.0\" }, \"remediation\": null, \"durationMs\": 0 }, \"runtime.search\": { \"id\": \"runtime.search\", \"category\": \"search\", \"status\": \"ok\", \"summary\": \"search is OK (system)\", \"details\": { \"search command\": \"rg.exe\", \"search command readiness\": \"ripgrep 15.1.0 (rev af60c2de9d)\", \"search provider\": \"system\" }, \"remediation\": null, \"durationMs\": 272 }, \"sandbox.helpers\": { \"id\": \"sandbox.helpers\", \"category\": \"sandbox\", \"status\": \"ok\", \"summary\": \"sandbox configuration is readable\", \"details\": { \"approval policy\": \"OnRequest\", \"codex-linux-sandbox helper\": \"none\", \"execve wrapper helper\": \"none\", \"filesystem sandbox\": \"restricted\", \"network sandbox\": \"restricted\" }, \"remediation\": null, \"durationMs\": 0 }, \"state.paths\": { \"id\": \"state.paths\", \"category\": \"state\", \"status\": \"ok\", \"summary\": \"state paths and databases are inspectable\", \"details\": { \"CODEX_HOME\": \"C:\\\\Users\\\\CMJ\\\\.codex (dir)\", \"active rollout files\": \"42 files, 25233260 total bytes, 600791 average bytes\", \"archived rollout files\": \"0 files, 0 total bytes, 0 average bytes\", \"log DB\": \"C:\\\\Users\\\\CMJ\\\\.codex\\\\logs_2.sqlite (file)\", \"log DB integrity\": \"ok\", \"log dir\": \"C:\\\\Users\\\\CMJ\\\\.codex\\\\log (dir)\", \"sqlite home\": \"C:\\\\Users\\\\CMJ\\\\.codex (dir)\", \"state DB\": \"C:\\\\Users\\\\CMJ\\\\.codex\\\\state_5.sqlite (file)\", \"state DB integrity\": \"ok\" }, \"remediation\": null, \"durationMs\": 2915 }, \"terminal.env\": { \"id\": \"terminal.env\", \"category\": \"terminal\", \"status\": \"ok\", \"summary\": \"terminal metadata was detected\", \"details\": { \"WT_SESSION\": \"present\", \"color output\": \"enabled\", \"stderr is terminal\": \"true\", \"stdin is terminal\": \"true\", \"stdout is terminal\": \"true\", \"terminal\": \"Windows Terminal\", \"terminal size\": \"120x30\" }, \"remediation\": null, \"durationMs\": 1 }, \"updates.status\": { \"id\": \"updates.status\", \"category\": \"updates\", \"status\": \"warning\", \"summary\": \"update configuration is locally consistent\", \"details\": { \"cached latest version\": \"0.132.0\", \"check for update on startup\": \"true\", \"last checked at\": \"2026-05-21T03:07:58.736275500Z\", \"latest version probe\": \"curl: (28) Operation timed out after 5013 milliseconds with 8287 out of 242098 bytes received\", \"npm update target\": \"C:\\\\Users\\\\CMJ\\\\AppData\\\\Roaming\\\\npm\\\\node_modules\\\\@openai\\\\codex\", \"update action\": \"npm install -g @openai/codex\", \"version cache\": \"C:\\\\Users\\\\CMJ\\\\.codex\\\\version.json\" }, \"remediation\": null, \"durationMs\": 5313 } } } ``` ### What issue are you seeing? no ### What steps can reproduce the bug? Windows PowerShell configuration: sandbox = \"elevated\", approval_policy = \"on-request\", sandbox_mode = \"workspace-write\". Git branch names fail to display in the statusline with these settings. ### What is the expected behavior? not possible ### Additional information Windows PowerShell configuration: sandbox = \"elevated\", approval_policy = \"on-request\", sandbox_mode = \"workspace-write\". Git branch names fail to display in the statusline with these settings.", "url": "https://github.com/openai/codex/issues/23968", "createdAt": "2026-05-22T00:46:45Z", "updatedAt": "2026-08-13T01:55:20Z", "timestamp": "2026-08-13T01:55:20Z", "metrics": { "reactions": 0, "comments": 4 }, "labels": [ "bug", "windows-os", "sandbox", "TUI" ], "author": "mujuncool", "state": "open", "assignees": [] }, { "id": "github:openai/codex:issue:24204", "source": "github", "group": "coding-agent-infrastructure", "project": "openai/codex", "kind": "issue", "title": "sandbox escalation approval times out after Codex update; CLI cannot access macOS Keychain", "text": "Summary After updating Codex Desktop, commands that require sandbox escalation no longer run. The escalation reviewer times out before approving the command. As a result, tools such as lark-cli cannot access macOS Keychain from Codex, even though the same commands work successfully in the user's normal terminal. Impact This blocks Codex from using locally configured CLI tools that store credentials in macOS Keychain. In this case, Feishu/Lark CLI is installed and authenticated, but Codex cannot read documents or write Base records because it cannot run lark-cli outside the sandbox. Environment Codex app binary: /Applications/Codex.app/Contents/Resources/codex Codex CLI version: codex-cli 0.133.0-alpha.1 macOS: 26.5, build 25F71 Architecture: arm64 Workspace: /Users/roger/Desktop/AI Product OS Filesystem sandbox mode: workspace-write Feishu/Lark CLI path: /Users/roger/.npm-global/bin/lark-cli Feishu/Lark CLI version: 1.0.39 Expected Behavior When Codex requests escalated execution for a command such as: lark-cli auth status the approval flow should complete, the command should run outside the sandbox, and the CLI should be able to read the macOS Keychain credential. Actual Behavior Escalated commands fail before execution with: Rejected(\"The automatic permission approval review did not finish before its deadline. Do not assume the action is unsafe based on the timeout alone. You may retry once, or ask the user for guidance or explicit approval.\") When the same command is run without escalation, Codex's sandbox cannot access Keychain and returns: { \"ok\": false, \"error\": { \"type\": \"config\", \"message\": \"keychain Get failed: keychain not initialized\", \"hint\": \"The keychain master key may have been cleaned up or deleted. If running inside a sandbox or CI environment, please ensure the process has the necessary permissions to access the keychain, you can try running this outside the sandbox. Otherwise, please reconfigure the CLI by running lark-cli config init.\" } } Important Control Check The same commands work in the user's normal macOS terminal: lark-cli auth status lark-cli doctor The user reports lark-cli doctor returns ok: true in the terminal, including valid bot/user identity and reachable Feishu endpoints. This indicates the Feishu CLI, user authorization, and macOS Keychain are healthy outside Codex. Reproduction Steps Install/configure Feishu CLI: npx @larksuite/cli@latest install lark-cli config init --new lark-cli auth login --recommend Confirm in normal terminal: lark-cli doctor It returns ok: true. In Codex Desktop, run: lark-cli auth status Without escalation, it fails with keychain Get failed. In Codex Desktop, request escalated execution for: lark-cli auth status The escalation attempt times out with the approval reviewer deadline error and the command does not run. Regression Signal The same workflow worked before the Codex Desktop update. Earlier in the same project, Codex successfully executed Feishu CLI commands with sandbox escalation, read Feishu documents, and wrote to Feishu Base. After the Codex update, all lark-cli commands requiring Keychain access are blocked by escalation approval timeout. Requested Help Please investigate whether Codex Desktop 0.133.0-alpha.1 has a regression in sandbox escalation approval handling on macOS, especially for commands that require Keychain access. A workaround or instructions for resetting the local approval reviewer would also help.", "url": "https://github.com/openai/codex/issues/24204", "createdAt": "2026-05-23T06:40:29Z", "updatedAt": "2026-08-13T10:57:37Z", "timestamp": "2026-08-13T10:57:37Z", "metrics": { "reactions": 1, "comments": 4 }, "labels": [ "bug", "sandbox", "app" ], "author": "rogerliangyujie32-maker", "state": "open", "assignees": [] }, { "id": "github:openai/codex:issue:24280", "source": "github", "group": "coding-agent-infrastructure", "project": "openai/codex", "kind": "issue", "title": "Remote-created Codex Desktop threads on connected host do not receive automation_update/load_workspace_dependencies", "text": "## 1. Feedback ID 019e4c10-cadb-7e70-8bf8-38245507bc2f ## 2. Product Codex Desktop App / Remote Control / app-server `thread/start` dynamic tool provisioning. ## 3. Environment - Host: always-on Mac Mini running Codex Desktop - Client: MacBook Pro using the Codex remote workflow against the Mac Mini host - Host project path: `~/Documents/Codex/projects/business-intake-task-system` - Codex Desktop app/server version observed in logs: `26.519.41501` - CLI/session version: `codex-cli 0.133.0-alpha.1` - Platform: macOS / Darwin / Apple Silicon Hostnames, user account paths, raw logs, databases, auth files, and unrelated prompt content are intentionally not included here. ## 4. Summary Brand-new Codex Desktop threads created locally on the Mac Mini host receive the expected built-in Codex app dynamic tools: - `codex_app.automation_update` - `codex_app.read_thread_terminal` - `codex_app.load_workspace_dependencies` Brand-new threads created from the MacBook Pro remote workflow against the same Mac Mini host and same project receive only: - `codex_app.read_thread_terminal` If a thread is created locally on the Mac Mini first and then continued from the MacBook Pro, the full tool set remains available. So remote continuation works, host-local thread creation works, but brand-new remote thread creation appears to persist a reduced dynamic-tool set at thread creation time. ## 5. Steps to reproduce 1. On a Mac Mini host running Codex Desktop, open a new project thread locally for a project path such as `~/Documents/Codex/projects/business-intake-task-system`. 2. Confirm the thread has `codex_app.automation_update`, `codex_app.read_thread_terminal`, and `codex_app.load_workspace_dependencies`. 3. From a MacBook Pro, use the Codex remote workflow to create a brand-new thread on the same Mac Mini host and same project path. 4. Inspect the new remote-created thread's dynamic tools. 5. Separately, create a thread locally on the Mac Mini first, then continue that same thread from the MacBook Pro. ## 6. Expected behavior A brand-new remote-created thread on a connected host should receive the same built-in Codex app dynamic tools as an equivalent host-local thread for the same project. If remote-created threads are intentionally not automation-capable, Codex should clearly label them as such and provide an action to create or open an automation-capable host-local thread. ## 7. Actual behavior Remote-created brand-new threads look like normal user project threads but are persisted with only `codex_app.read_thread_terminal`. They do not receive `codex_app.automation_update` or `codex_app.load_workspace_dependencies`, so they cannot create or update Codex automations. ## 8. Confirmed PASS cases ### Mac Mini direct via deep link - Session: `019e5690-baaa-7161-8e15-5b3cbe023ffa` - Dynamic tools: - `codex_app.automation_update` - `codex_app.read_thread_terminal` - `codex_app.load_workspace_dependencies` - App-server indicator: `connection_id=0` - Heartbeat/thread permission state: present in `.codex-global-state.json` ### Mac Mini direct via normal Codex App UI new thread - Session: `019e5694-641d-79a3-9447-54f86074e996` - Dynamic tools: - `codex_app.automation_update` - `codex_app.read_thread_terminal` - `codex_app.load_workspace_dependencies` - App-server indicator: `connection_id=0` - Heartbeat/thread permission state: present ## 9. Confirmed FAIL cases ### MacBook Pro remote workflow, brand-new thread on the Mac Mini host - Session: `019e5697-260c-7d73-8941-4db90e80b7e6` - Dynamic tools: - `codex_app.read_thread_terminal` - Missing: - `codex_app.automation_update` - `codex_app.load_workspace_dependencies` - App-server indicator: `connection_id=12` - Heartbeat/thread permission state: absent ### Second MacBook Pro remote-created failing-pattern thread - Session: `019e56fe-b398-7c32-8768-2f3e656d0828` - Dynamic tools: - `codex_app.read_thread_terminal` - Missing: - `codex_app.automation_update` - `codex_app.load_workspace_dependencies` - App-server indicator: `connection_id=23` - Heartbeat/thread permission state: absent ## 10. Remote continuation result A Mac Mini-created thread was continued from the MacBook Pro: - Session: `019e5690-baaa-7161-8e15-5b3cbe023ffa` - Dynamic tools remained: - `codex_app.automation_update` - `codex_app.read_thread_terminal` - `codex_app.load_workspace_dependencies` This shows the MacBook Pro remote client can continue and use an automation-capable thread. The failure is specific to brand-new remote thread creation. ## 11. Evidence - `state_5.sqlite` thread rows are materially identical across pass/fail for `cwd`, `source`, `thread_source`, model, sandbox, approval mode, CLI version, and memory mode. - `state_5.sqlite` `thread_dynamic_tools` differs: - host-local created threads: 3 tools - remote-created threads: 1 tool - Session JSONL `session_meta.dynamic_tools` differs on the first `session_meta` line, so the mismatch exists at or before session creation. - `logs_2.sqlite` shows both paths using `rpc.method=thread/start` and `rpc.transport=stdio` with `client_name=Codex Desktop` and `client_version=26.519.41501`. - The visible differentiator is app-server connection identity: - host-local creation: `connection_id=0` - remote new-thread creation: nonzero remote connection IDs such as `connection_id=12` and `connection_id=23` - `.codex-global-state.json` `heartbeat-thread-permissions-by-id` has entries for host-created passing threads but not for remote-created failing threads. - No log evidence showed `automation_update` being denied or filtered by entitlement, policy, sandbox, or approval settings. ## 12. Important negative findings - `source=vscode` is not causal. Passing and failing threads both report `source=vscode`. - GitHub Copilot Chat appears unrelated. - No active Codex/OpenAI/ChatGPT VS Code extension or bridge was found during inspection. - VS Code was not running during inspection. - Remote continuation does not strip `automation_update`. ## 13. Suspected root cause The remote `thread/start` path appears to skip or use a reduced built-in dynamic-tool provisioning branch. It attaches `read_thread_terminal` but omits `automation_update` and `load_workspace_dependencies`, and it does not seed the same heartbeat/thread permission state that host-local thread creation seeds. ## 14. Workaround Create the thread locally on the Mac Mini first, using either the Codex App UI or a deep link like: ```sh open 'codex://threads/new?path=/Users//Documents/Codex/projects/business-intake-task-system' ``` Then continue that same thread from the MacBook Pro. Remote continuation preserves `automation_update`. ## 15. Scrubbed local evidence available I can provide scrubbed excerpts from the relevant `thread_dynamic_tools`, `session_meta.dynamic_tools`, and app-server log rows if maintainers want them. I am not attaching raw logs, full JSONL files, auth files, database files, or unrelated prompt content because they may contain sensitive local context.", "url": "https://github.com/openai/codex/issues/24280", "createdAt": "2026-05-23T23:33:07Z", "updatedAt": "2026-08-12T22:48:45Z", "timestamp": "2026-08-12T22:48:45Z", "metrics": { "reactions": 6, "comments": 5 }, "labels": [ "bug", "app", "app-server", "remote", "automations" ], "author": "jm-fhc", "state": "open", "assignees": [ "ax-openai" ] }, { "id": "github:openai/codex:issue:24307", "source": "github", "group": "coding-agent-infrastructure", "project": "openai/codex", "kind": "issue", "title": "Prefix `./` to completion of `@{filename}` if the path is not obviously a path", "text": "### What variant of Codex are you using? CLI ### What feature would you like to see? This is similar to https://github.com/openai/codex/issues/6915, but the feature request is different: the author request for `@` to be kept after the tab completion. Instead, I propose the following: say there's a file `hello` in the current directory, you type `@h` and `tab`, it will complete to `hello`. Since the agent has no idea that it was tab-completed from a filename, it wouldn't know it's intended to be a filename. It would be better (and still reasonably backwards compatible) to: if the file does not have an extension and is in the current directory, prefix `./`. So in the example above the agent will see `./hello` which is obviously a file path. ### Additional information _No response_", "url": "https://github.com/openai/codex/issues/24307", "createdAt": "2026-05-24T07:47:37Z", "updatedAt": "2026-08-13T14:51:13Z", "timestamp": "2026-08-13T14:51:13Z", "metrics": { "reactions": 0, "comments": 3 }, "labels": [ "enhancement", "TUI", "CLI" ], "author": "user202729", "state": "open", "assignees": [] }, { "id": "github:openai/codex:issue:24535", "source": "github", "group": "coding-agent-infrastructure", "project": "openai/codex", "kind": "issue", "title": "Codex Desktop voice transcription failures can discard unrecoverable audio", "text": "### What happened? In Codex Desktop, voice input / speech-to-text can fail or produce an obviously incomplete transcription. When that happens, the original recorded audio appears to be unavailable: it is not attached to the conversation, not referenced in the session JSONL, and not discoverable in the local Codex cache or transcription history. This makes voice input risky for longer or important recordings, because a transcription failure can mean the user loses both the transcription and the original audio. ### Why this matters For use cases like interviews, meetings, notes, or spoken bug reports, users may rely on Codex voice input as the capture mechanism. If STT fails and the raw audio is discarded, there is no recovery path. ### Observed behavior - The session JSONL only recorded the user text event and did not contain an audio attachment or local audio path. - `~/.codex/transcription-history.jsonl` contained only the transcription text, not the source audio file path. - Searching common local locations such as the workspace, `~/.codex`, Codex application support/cache directories, `/tmp`, and `/var/folders` did not reveal a corresponding audio file. - In one case the resulting transcription was only a tiny fragment (for example, `嗯?`) even though the intended recording was much longer. ### Expected behavior Codex should provide a recovery path when voice transcription fails or produces incomplete output. Possible fixes: 1. Keep the original audio locally until the transcription succeeds and the user sends/accepts it. 2. If transcription fails, expose a retry option using the original audio. 3. Attach or link the temporary audio file in the session record until the turn is complete. 4. Make the retention behavior explicit in the UI, especially for longer recordings. 5. Consider saving failed voice captures to a recoverable local folder, with a clear privacy/retention policy. ### Environment - App: Codex Desktop - Platform: macOS - CLI version observed in session metadata: `0.133.0-alpha.1` - Source: VS Code / Codex Desktop session ### Additional context This issue is about reliability and data recovery, not transcription accuracy alone. Even if transcription can fail occasionally, the user should not lose the original audio without a way to retry or recover it.", "url": "https://github.com/openai/codex/issues/24535", "createdAt": "2026-05-26T05:51:17Z", "updatedAt": "2026-08-12T14:54:26Z", "timestamp": "2026-08-12T14:54:26Z", "metrics": { "reactions": 2, "comments": 3 }, "labels": [ "bug", "app" ], "author": "yisiliang", "state": "open", "assignees": [], "change": "updated" }, { "id": "github:openai/codex:issue:24550", "source": "github", "group": "coding-agent-infrastructure", "project": "openai/codex", "kind": "issue", "title": "Responses WebSocket falls back when compacted replacement_history contains large inline images", "text": "### What version of Codex CLI is running? `codex-cli 0.133.0`. The original affected session metadata includes `codex-cli 0.130.0`, but the WebSocket fallback was reproduced from a copied session using the current Codex CLI/App around `0.133.0`. ### What subscription do you have? ChatGPT Pro 20x. ### Which model were you using? `gpt-5.5` with `reasoning_effort=xhigh`. ### What platform is your computer? macOS arm64. ### What terminal emulator and version are you using (if applicable)? iTerm2 3.6.10. The affected thread was resumed through Codex CLI/App flows. The reproduction used copied `CODEX_HOME` directories and `codex resume` against the same session JSONL payload. No terminal multiplexer was intentionally used for the reproduction session; separate monitoring/caffeinate processes may have been run in other terminals. ### Codex doctor report Redacted summary from `codex doctor --json`: - overallStatus: `ok` - codexVersion: `0.133.0` - install method: `brew` - runtime platform: `macos-aarch64` - installation: `installation looks consistent` - config: `config loaded` - model: `gpt-5.5` - model provider: `openai` - auth: `auth is configured` - auth mode: `chatgpt` - provider reachability: `active provider endpoints are reachable over HTTP` - WebSocket reachability: `Responses WebSocket handshake succeeded` - WebSocket handshake result: `HTTP 101 Switching Protocols` - WebSocket wire API: `responses` - terminal: `iTerm2` - terminal version: `3.6.10` - terminal size: `211x98` - state paths: `state paths and databases are inspectable` - active rollout files: `110 files, 1371653678 total bytes, 12469578 average bytes` I am not pasting the raw doctor JSON because it contains local usernames, paths, project names, and state locations. ### What issue are you seeing? A long-running Codex thread consistently falls back from Responses WebSocket to HTTPS when resumed. This may share a root cause with #24388, because both involve large `input_image` payloads retained inside compacted `replacement_history`. The observed failure mode here is different: instead of remote compaction failing with `context_length_exceeded`, the Responses WebSocket stream closes before `response.completed`, retries several times, and then falls back to HTTP. I was able to reproduce the fallback using a copied `CODEX_HOME`, and then eliminate the fallback by removing only inline image payloads from compacted `replacement_history`. Observed WebSocket failure pattern: ```text stream disconnected - retrying sampling request (1/5 ...) stream disconnected - retrying sampling request (2/5 ...) stream disconnected - retrying sampling request (3/5 ...) stream disconnected - retrying sampling request (4/5 ...) stream disconnected - retrying sampling request (5/5 ...) falling back to HTTP ``` The HTTP fallback then proceeds, but the affected thread becomes prone to long idle periods. ### What steps can reproduce the bug? I cannot attach the raw session JSONL because it contains local paths, prompts, tool output, and image payloads. The structural reproduction I used was: 1. Start from a long-running Codex thread with multiple compactions and historical image inputs. 2. Confirm that compacted `replacement_history` contains retained `input_image` payloads. 3. Copy the affected session JSONL into a clean temporary `CODEX_HOME`. 4. Resume the same thread from the copied session. 5. Observe that WebSocket warmup succeeds, but the actual resumed turn payload fails over WebSocket, retries 5 times, and falls back to HTTP. 6. Create another copy of the same session JSONL. 7. Replace only `input_image` items inside `type: \"compacted\"` records with small text placeholders. 8. Resume the same thread from that sanitized copy. 9. Observe that `responses_websocket` completes normally, with no HTTP fallback and no `stream disconnected` retries. Control reproduction with copied session JSONL: - WebSocket warmup succeeded. - The actual resumed turn payload failed over WebSocket. - `stream disconnected` occurred 5 times. - Codex fell back to HTTP. This suggests the issue is reproducible from the session/history payload itself, not from the original live `~/.codex` state. Compaction-only sanitized reproduction: - I replaced only `input_image` items inside `type: \"compacted\"` records with text placeholders. - Non-compacted history was left mostly unchanged. Before sanitization: - Session JSONL size: ~703 MB - Largest compacted JSONL line: ~17.4 MB - Total `input_image` entries: 1789 - `input_image` entries inside compacted records: 1277 - `input_image` entries outside compacted records: 512 - Latest compacted `replacement_history`: ~17.39 MB - Inline image data in that replacement history: ~17.17 MB - Image data share of replacement history: ~98.75% After compaction-only sanitization: - Session JSONL size: ~195 MB - Largest compacted JSONL line: ~241 KB - `input_image` entries inside compacted records: 0 - `input_image` entries outside compacted records: 509 Result: - `responses_websocket` completed normally. - `responses_http`: 0 - `stream disconnected`: 0 - fallback: 0 - turn completed successfully. This suggests the failure is specifically tied to inline images retained in compacted `replacement_history`, not simply to any historical `input_image` item anywhere in the session JSONL. I also tested a full-image-sanitized copy, where all `input_image` items were replaced with text placeholders. That also completed normally over WebSocket. ### What is the expected behavior? Either: - compacted `replacement_history` should not retain large raw inline image payloads unnecessarily, - the Responses WebSocket transport should handle this payload shape reliably, - Codex should surface a more specific close reason, such as payload size / unsupported multimodal replay / request shape issue, or - Codex should automatically recover from this history shape without requiring manual session JSONL surgery. A session should not repeatedly fail Responses WebSocket and silently fall back to HTTP because compacted history retained large inline image payloads. ### Additional information The thread did not always fail WebSocket. It worked over WebSocket for several days before the first hard fallback. The first hard fallback appeared after a compaction where `replacement_history` had grown to ~17.38 MB and contained 42 inline images. In the latest compaction: - Messages in replacement history: 382 - Messages containing images: 18 - `input_image` count in replacement history: 42 - Image bytes inside image-containing messages: ~99.88% of those messages The images appear to be retained as historical user message content inside compacted replacement history. Privacy note: I am not attaching raw rollout/session files because they contain private prompts, tool output, local paths, and inline image data. I can provide further redacted structural data if useful.", "url": "https://github.com/openai/codex/issues/24550", "createdAt": "2026-05-26T07:56:01Z", "updatedAt": "2026-08-13T09:50:27Z", "timestamp": "2026-08-13T09:50:27Z", "metrics": { "reactions": 1, "comments": 6 }, "labels": [ "bug", "CLI", "context", "connectivity" ], "author": "KwakYounHo", "state": "open", "assignees": [] }, { "id": "github:openai/codex:issue:24649", "source": "github", "group": "coding-agent-infrastructure", "project": "openai/codex", "kind": "issue", "title": "When exactly will Codex fix the recent slowdown and quality degradation?", "text": "Codex has felt noticeably slower and less capable over the past several days. The slowdown and quality degradation started over the weekend, and now it is already Tuesday, but the issue still does not appear to be fixed. The main problems I am seeing are: - Tasks that used to finish much faster are now taking significantly longer. - The quality of the output has become noticeably worse, especially on coding and debugging tasks. - Some tasks now waste a large amount of time and usage, while still producing results that need to be reverted or redone. - As a $200/month Pro subscriber, this experience feels very disappointing and not worth the cost right now. Codex is serving a global market, so it should be able to provide stable 24/7 operation. If users in California cannot reliably use Codex during normal daytime hours or over the weekend, what about users in the Eastern Hemisphere? Is there enough operational coverage during weekends and off-hours to monitor and maintain service quality? This is not just a small inconvenience for paying users. Codex needs to meet basic expectations for stability, speed, and output quality. Could the team please provide a clear update on whether this slowdown and quality regression is known, whether it is being actively investigated, and when users can expect normal performance to be restored? Please prioritize this urgently. Right now, the experience does not feel acceptable for a paid Pro user, and basic customer expectations are not being met.", "url": "https://github.com/openai/codex/issues/24649", "createdAt": "2026-05-26T21:42:14Z", "updatedAt": "2026-08-13T02:52:48Z", "timestamp": "2026-08-13T02:52:48Z", "metrics": { "reactions": 16, "comments": 9 }, "labels": [ "bug", "model-behavior", "performance" ], "author": "GGBondBlueWhale", "state": "open", "assignees": [] }, { "id": "github:openai/codex:issue:24770", "source": "github", "group": "coding-agent-infrastructure", "project": "openai/codex", "kind": "issue", "title": "Plugin install: support symlinks per the cross-agent marketplace contract", "text": "## Summary `codex plugins install` (local marketplace path) silently drops symlinks from the plugin source tree when materializing the plugin into the install cache at `~/.codex/plugins/cache////`. Marketplace authors who use the standard pattern of symlinking a shared skill or shared script directory into a plugin folder end up with either an empty `skills/` dir or a partially populated plugin tree — with no error, no warning, and no log line. This makes it impossible to maintain a marketplace with a shared `skills/` (or `scripts/`, `references/`, etc.) directory and lightweight \"meta-plugins\" that compose those shared pieces — which is one of the most common marketplace layouts in the broader community. ## Specific problem The recursive copy used during plugin install only handles two file types and falls off the end for symlinks (`codex-rs/core-plugins/src/store.rs`, `copy_dir_recursive`): ```rust fn copy_dir_recursive(source: &Path, target: &Path) -> Result<(), PluginStoreError> { fs::create_dir_all(target) .map_err(|err| PluginStoreError::io(\"failed to create plugin target directory\", err))?; for entry in fs::read_dir(source) .map_err(|err| PluginStoreError::io(\"failed to read plugin source directory\", err))? { let entry = entry .map_err(|err| PluginStoreError::io(\"failed to read plugin source entry\", err))?; let source_path = entry.path(); let target_path = target.join(entry.file_name()); let file_type = entry .file_type() .map_err(|err| PluginStoreError::io(\"failed to inspect plugin source entry\", err))?; if file_type.is_dir() { copy_dir_recursive(&source_path, &target_path)?; } else if file_type.is_file() { fs::copy(&source_path, &target_path) .map_err(|err| PluginStoreError::io(\"failed to copy plugin file\", err))?; } } ``` `entry.file_type()` uses `lstat` semantics, so a symlink-to-directory returns `is_symlink() == true`, `is_dir() == false`, `is_file() == false`. The code has no third branch, so the entry is **silently skipped** — no error, no `tracing` event, no UI surface. Concrete repro (a very common community pattern): ```text my-marketplace/ ├── .agents/plugins/marketplace.json ├── skills/ # shared skill library at marketplace root │ └── skillgroup/ │ └── skillX/ │ └── SKILL.md └── plugins/ └── pluginX/ ├── .codex-plugin/plugin.json └── skills/ └── skillX -> ../../../skills/skillgroup/skillX # symlink ``` After `codex plugins install pluginX@my-marketplace`, the cache contains `~/.codex/plugins/cache/my-marketplace/pluginX//skills/` as an empty directory. The skill is unreachable. The skill *discovery* code is fine — it already follows symlinks at scope `User`/`Repo`/`Admin` ([#8801]()) — the bug is upstream of discovery, in the install copy. ## Proposed solution (high level) Support symbolic links in plugin folders during install by implementing the three-way contract already specified by other agentic tools' plugin marketplaces: [**Plugins reference → Share files within a marketplace with symlinks**]() | Where the symlink target resolves | Cache behavior | | -- | -- | | Inside the plugin's own directory | **Preserve** as a relative symlink (keeps resolving to the copied target at runtime) | | Inside the same marketplace, outside the plugin | **Dereference** — copy the target's real content into the cache in its place | | Outside the marketplace | **Skip** (security) | | `--plugin-dir` / direct local install (no marketplace context) | Only same-plugin links are preserved; everything else is skipped | Adopting this contract verbatim gives Codex three things at once: 1. **Unblocks the shared-resource marketplace layout** that's a very common community pattern. 2. **Consistency across agentic CLIs.** Plugin authors can ship the same marketplace layout to Codex and to other agentic tools with identical behavior. No \"works elsewhere, silently empty in Codex\" footgun. Reduces porting friction for the growing set of plugin/skill authors maintaining marketplaces that target multiple agents. 3. **Better security posture than blanket \"follow all symlinks\"** — the third bucket explicitly refuses to pull arbitrary host files (e.g., `/etc/...`, `~/.ssh/...`) into the plugin cache, which is exactly the concern the existing tar-bundle path already enforces by rejecting all link entries in `core-plugins/src/plugin_bundle_archive.rs`. ## Signal of need This bug, or its near neighbors, has been independently rediscovered and reported by multiple users: * openai/codex#18863 — *Plugin cache install silently drops symlinks from local plugin sources* (open, labels: `bug`, `skills`). The canonical bug report. Includes root-cause analysis pointing at `copy_dir_recursive`, exactly the function quoted above, plus three regression tests already written and verified locally by the reporter. * openai/codex#17952 — *fix: preserve plugin cache symlinks* (closed). Two maintainers both **approved** this PR on Apr 15, 2026. It was then auto-closed by the stale-bot on Apr 30 due to no updates — never merged. The PR implemented \"preserve\" (bucket 1 above) only; the contract proposed here generalizes it to all three buckets so it stays correct for shared-resource layouts too. * openai/codex#17066 — *Marketplace local plugin path \"./\" cannot reference the repository root* (open). Adjacent issue: users hit this when they try the workaround of placing the plugin at the marketplace root to avoid the symlink path altogether. The reporter's \"current workaround A\" relies on a `skills` symlink crossing the plugin boundary — which is exactly the case this proposal makes work natively. Closes openai/codex#18863. Supersedes (and generalizes) the approved patch in openai/codex#17952. Removes the need for workaround A in openai/codex#17066, though that issue tracks a separate marketplace-path-validation bug and should stay open on its own merits. ## Proposed Solution Details ### Required tasks 1. `codex-rs/core-plugins/src/store.rs` * Replace `copy_dir_recursive` with a boundary-aware `copy_plugin_tree` that takes `plugin_root` and `Option`, walks the source with `lstat` semantics (the existing `entry.file_type()`), and dispatches each symlink to one of three handlers per the contract above. * Add a small `SymlinkDisposition` enum (`PreserveRelative` / `Dereference` / `Skip`) and a `classify_symlink_target` helper that canonicalizes the link and tests path containment against the two boundary roots. * Add a `recreate_relative_symlink` helper that re-emits the original `read_link` text verbatim (so the cached link string is portable) and selects `symlink_dir` vs `symlink_file` on Windows. * Add a visited-set carried through the recursion for cycle protection on the dereference branch (mirrors what `core-skills/src/loader.rs::canonicalize_for_skill_identity` already does for the discovery walker). * Update the call site inside `PluginStore::install_plugin` (and the staging helper that wraps `copy_dir_recursive`) to thread the boundary roots through. 2. `codex-rs/core-plugins/src/manager.rs` **(and** `core-plugins/src/marketplace_add/install.rs`**)** * Plumb the marketplace root into the `PluginStore::install_plugin` call. The marketplace path is already known at install time (it's the directory `clone_git_source` / local-path resolution produced). * For direct local-path installs that have no marketplace concept, pass `None` so the routine falls back to the documented `--plugin-dir` rule (same-plugin preserve, everything else skip). 3. `codex-rs/core-plugins/src/store.rs` **— tests** (new module, or extend `store_tests.rs`) * `install_preserves_symlink_inside_plugin_dir` * `install_dereferences_symlink_to_sibling_plugin_in_same_marketplace` * `install_dereferences_symlink_to_shared_dir_at_marketplace_root` ← the canonical \"shared skills\" layout * `install_skips_symlink_targeting_path_outside_marketplace` * `install_for_direct_local_path_skips_symlinks_outside_plugin_dir` * `install_preserves_relative_link_text_verbatim` (use `fs::read_link` after install to assert) * `install_handles_symlink_cycle_within_marketplace_without_infinite_recursion` * `install_skips_dangling_symlink_without_failing` * Gate the symlink-creation portions on non-Windows where appropriate; on Windows, gate behind `std::os::windows::fs::symlink_*` availability. 4. `codex-rs/core-plugins/src/plugin_bundle_archive.rs` * Audit the existing `InvalidBundle` rejection at the `is_hard_link() || is_symlink()` arm to confirm it remains the right policy for the tar path (it is — bundles are meant to be self-contained). No behavior change required, but worth a comment cross-referencing the new local-install contract so future contributors understand the asymmetry. 5. `docs/plugins.md` **(or wherever the plugin authoring docs live in** `codex-rs`**'s docs surface)** * Add a \"Sharing files within a marketplace with symlinks\" subsection mirroring the same wording authors targeting other agentic tools already follow. ### Optional / deferrable These can be split into follow-up PRs without blocking the core fix: * *(Optional, polish)* When a symlink is skipped because it falls in bucket 3, emit a `tracing::warn!` (not just `debug`) once per install and surface a single aggregate hint in the `codex plugins install` CLI output (\"N symlink(s) outside the marketplace were skipped\"). Quicker fix: just `debug!` it for now. * *(Optional)* Treat a dangling symlink (read_link succeeds, canonicalize fails) as a hard `InvalidBundle`-style error rather than a silent skip, parameterized by a `strict` flag on the install call. Quicker fix: silent skip with a `debug!` line, matching the default behavior on other agentic tools. * *(Optional)* Add a `paths.symlinks` field to the plugin manifest (`{ \"policy\": \"follow\" | \"preserve\" | \"reject\" }`) for plugins that want to opt into stricter behavior than the default. Not needed for the fix; only file as a follow-up if there's demand. * *(Optional)* If the maintainers prefer a minimal first cut to unblock users today, an acceptable interim implementation is **bucket 2 only** — dereference all symlinks in the plugin tree during install, with cycle protection — without yet distinguishing buckets 1 and 3. This restores the canonical shared-skills layout immediately and matches what the approved openai/codex#17952 intent was, then a follow-up PR can layer the full three-way contract on top. --- /cc @conrad-oai @dylan-hurd-oai @xl-openai", "url": "https://github.com/openai/codex/issues/24770", "createdAt": "2026-05-27T16:22:34Z", "updatedAt": "2026-08-13T10:36:40Z", "timestamp": "2026-08-13T10:36:40Z", "metrics": { "reactions": 0, "comments": 1 }, "labels": [ "bug", "CLI", "skills" ], "author": "jasonnvidia", "state": "open", "assignees": [] }, { "id": "github:openai/codex:issue:24777", "source": "github", "group": "coding-agent-infrastructure", "project": "openai/codex", "kind": "issue", "title": "Add scriptable Codex Cloud environment and task lifecycle management", "text": "## Proposal Add a comprehensive, scriptable Codex Cloud CLI/API surface for environment discovery, environment lifecycle management, repo-based task dispatch, task/session monitoring, and PR/result handoff. Today, `codex cloud exec --env ENV_ID ...` can submit work once the caller already knows an opaque server-side environment ID. The CLI also supports task `list`, `status`, `diff`, and `apply`, but there does not appear to be a public non-interactive workflow for discovering or managing the Codex Cloud environments that those tasks depend on. That means automation currently has to open the interactive `codex cloud` TUI or web UI, find an environment manually, copy an opaque ID, and paste it into scripts. This blocks reliable multi-repo dispatch, CI integration, and agent-driven workflows. ## Current Codex Cloud CLI gap Current public task commands are useful, but environment IDs remain the missing primitive: ```bash codex cloud exec --env ENV_ID \"...\" codex cloud list --env ENV_ID --json codex cloud status TASK_ID codex cloud diff TASK_ID codex cloud apply TASK_ID ``` The CLI can operate on a task or known environment, but scripts cannot yet: - list available environments, - resolve `owner/repo` to the correct environment, - create an environment for a repo, - update labels/default branches/pinned status, - delete/archive stale environments, - dispatch by repo without knowing an opaque environment ID, - monitor and continue a cloud task lifecycle in a fully scriptable way. ## Requested CLI surface ### Environment discovery and resolution ```bash codex cloud env list codex cloud env list --repo owner/repo codex cloud env list --json codex cloud env get ENV_ID --json codex cloud env resolve --repo owner/repo --json ``` JSON output should expose stable automation fields, for example: ```json [ { \"id\": \"env_...\", \"repo\": \"owner/repo\", \"label\": \"main\", \"branch\": \"main\", \"status\": \"ready\", \"is_pinned\": true, \"is_default\": true } ] ``` The exact schema can follow the backend model, but scripts need at least: environment ID, repo binding, label/display name, branch/default branch if applicable, status/readiness, pinned/default/preferred state, and enough metadata to disambiguate multiple environments for one repo. ### Repo-based task dispatch ```bash codex cloud exec --repo owner/repo \"implement/fix ...\" codex cloud exec --repo owner/repo --branch main \"implement/fix ...\" codex cloud exec --env ENV_ID \"implement/fix ...\" ``` `--repo` should resolve the environment internally using the same behavior as `codex cloud env resolve`. If repo resolution is ambiguous, interactive use can show choices, but non-interactive use should fail clearly and suggest a disambiguating flag such as `--env`, `--label`, or `--branch`. ### Environment lifecycle management ```bash codex cloud env create --repo owner/repo --branch main --label \"main\" codex cloud env update ENV_ID --label \"main\" --branch main codex cloud env pin ENV_ID codex cloud env unpin ENV_ID codex cloud env set-default ENV_ID codex cloud env delete ENV_ID --yes ``` Optional follow-ons depending on the backend model: ```bash codex cloud env rename ENV_ID \"new label\" codex cloud env archive ENV_ID codex cloud env restore ENV_ID ``` Mutation commands should be safe by default: - destructive actions require confirmation unless `--yes` is supplied; - all commands support `--json`; - create/update validate repo and branch bindings; - delete/archive refuses or warns for active, pinned, or default environments; - behavior matches the web UI/TUI canonical environment model. ### Task lifecycle controls Codex Cloud already has task `list`, `status`, `diff`, and `apply`. For parity with async coding-agent workflows, it would be useful to make the task lifecycle fully scriptable: ```bash codex cloud wait TASK_ID --timeout 1800 --interval 10 codex cloud logs TASK_ID --json codex cloud message TASK_ID \"additional instruction or answer\" codex cloud cancel TASK_ID codex cloud output TASK_ID --json ``` The goal is for automation to dispatch a task, wait until it completes or needs input, answer questions, retrieve the diff/result, and report the final URL/status without using the TUI. If Codex Cloud supports PR creation now or in the future, expose that result explicitly: ```json { \"task_id\": \"task_...\", \"status\": \"completed\", \"url\": \"https://...\", \"pull_request\": { \"url\": \"https://github.com/owner/repo/pull/123\", \"title\": \"...\", \"description\": \"...\" } } ``` ## Prior art: Jules feature parity Jules exposes this workflow as a first-class CLI/API surface, and it is a strong comparison point for Codex Cloud. Jules CLI provides: ```bash jules remote list --repo jules remote list --session jules remote new --repo owner/repo --session \"...\" jules remote pull --session SESSION_ID ``` The Jules API provides: - `GET /v1alpha/sources` to list connected repos/sources, - `GET /v1alpha/sources/{sourceId}` to inspect one source, - `POST /v1alpha/sessions` with `sourceContext.source` and `githubRepoContext.startingBranch`, - `automationMode: \"AUTO_CREATE_PR\"` for PR-producing sessions, - session states such as `QUEUED`, `PLANNING`, `AWAITING_PLAN_APPROVAL`, `AWAITING_USER_FEEDBACK`, `IN_PROGRESS`, `COMPLETED`, and `FAILED`, - `outputs[].pullRequest.url` when a PR is created. This makes Jules powerful for fleet workflows because an external dispatcher can: 1. enumerate connected repos, 2. resolve `owner/repo` to an internal source ID, 3. create many async cloud sessions, 4. poll status, 5. answer questions or approve plans, 6. collect PR URLs, 7. continue review/merge through GitHub. Codex Cloud has some of these pieces internally, especially environment discovery in the TUI and by-repo environment lookup, but the missing piece is a stable public CLI/API contract. ## Why this matters A complete Codex Cloud automation surface would let scripts and agents: - bootstrap Codex Cloud for a repo, - keep repo/environment metadata in sync, - dispatch tasks by stable repo slug instead of opaque environment ID, - run multi-repo issue/spec fanout, - track task state and output URLs, - retrieve diffs/results, - safely clean up stale environments. This is especially important for agentic workflows where the unit of work is naturally `owner/repo + prompt`, not `opaque environment ID + prompt`. ## Suggested phased implementation ### Phase 1: read / resolve / dispatch ```bash codex cloud env list [--repo owner/repo] [--json] codex cloud env get ENV_ID [--json] codex cloud env resolve --repo owner/repo [--json] codex cloud exec --repo owner/repo \"...\" ``` This solves the immediate automation gap without adding destructive operations. ### Phase 2: task lifecycle ```bash codex cloud wait TASK_ID codex cloud logs TASK_ID --json codex cloud message TASK_ID \"...\" codex cloud output TASK_ID --json ``` This makes cloud tasks usable end-to-end in scripts. ### Phase 3: environment mutation ```bash codex cloud env create --repo owner/repo --branch main --label \"main\" codex cloud env update ENV_ID --label \"...\" --branch main codex cloud env pin ENV_ID codex cloud env unpin ENV_ID codex cloud env set-default ENV_ID codex cloud env delete ENV_ID --yes ``` This completes the feature by letting automation maintain the environment layer, not just consume existing environments. ## Consistency considerations The CLI should use the same environment discovery and selection logic as the existing `codex cloud` TUI so CLI, TUI, IDE extensions, web, and future API surfaces agree. Prefer command names that can grow: ```bash codex cloud env list/get/resolve/create/update/delete ``` A compatibility alias like `codex cloud list-envs` could still be useful, but the durable model should be a full `env` subcommand group. ## Prototype branch I implemented a smaller Phase 1 prototype here, but this repo currently only accepts PRs from collaborators: https://github.com/Kurry/codex/tree/codex-cloud-env-list The prototype currently covers: - `codex cloud list-envs` / `codex cloud envs` - `codex cloud list-envs --json` - `codex cloud list-envs --repo owner/repo --json` - `codex cloud exec --repo owner/repo ...` Validation run on the prototype: - `just fmt` - `just fix` - `cargo test -p codex-cloud-tasks` - `cargo test -p codex-cli`", "url": "https://github.com/openai/codex/issues/24777", "createdAt": "2026-05-27T16:46:58Z", "updatedAt": "2026-08-13T16:26:45Z", "timestamp": "2026-08-13T16:26:45Z", "metrics": { "reactions": 4, "comments": 1 }, "labels": [ "enhancement", "CLI" ], "author": "Kurry", "state": "open", "assignees": [] }, { "id": "github:openai/codex:issue:25178", "source": "github", "group": "coding-agent-infrastructure", "project": "openai/codex", "kind": "issue", "title": "Windows Computer Use screenshot fails on Windows 10 22H2 when SetIsBorderRequired is called", "text": "### Summary On Windows Codex Desktop, Computer Use can list apps/windows, activate windows, read accessibility text, and send keyboard input, but any `get_window_state` call that requests a screenshot fails before capture with: ```text SetIsBorderRequired failed: 不支持此接口 (0x80004002) ``` The same target window works when requesting accessibility text only (`include_screenshot: false, include_text: true`). This looks like the Windows capture helper unconditionally calls `GraphicsCaptureSession.IsBorderRequired` / `SetIsBorderRequired` on a Windows build that does not support that property. ### Environment Sanitized user machine details: - Platform: Windows Codex Desktop - Codex app package observed: `OpenAI.Codex_26.527.3686.0_x64__2p2nqsd0c76g0` - Computer Use plugin observed: `computer-use/26.527.31326` - OS: Windows 10 Pro 22H2 - OS build: `10.0.19045` - GPU: NVIDIA GeForce GTX 1060 3GB - DirectX: 12 - Driver model: WDDM 2.7 - Remote/virtual display drivers also present: ToDesk Virtual Display Adapter, Oray Display Mirror Driver ### Reproduction From the Computer Use client in Codex Desktop on this Windows 10 machine: 1. Bootstrap Computer Use and call `sky.list_apps()`. 2. Open or select a simple window such as Notepad. 3. Activate the window. 4. Call any screenshot-including state request, for example: ```js await sky.get_window_state({ window: targetWindow }); // or await sky.get_window_state({ window: targetWindow, include_screenshot: true, include_text: false }); // or await sky.get_window_state({ window: targetWindow, include_screenshot: true, include_text: true }); ``` 5. The call fails with: ```text SetIsBorderRequired failed: 不支持此接口 (0x80004002) ``` 6. Calling text-only succeeds: ```js await sky.get_window_state({ window: targetWindow, include_screenshot: false, include_text: true }); ``` Observed text-only result against Notepad included a focused editor element and accessibility tree, proving that the helper, native pipe, app enumeration, activation, and accessibility path are otherwise working. ### Observed Batch Test Results ```json { \"notepad_default_screenshot\": \"failed: SetIsBorderRequired failed: 不支持此接口 (0x80004002)\", \"notepad_explicit_screenshot\": \"failed: SetIsBorderRequired failed: 不支持此接口 (0x80004002)\", \"notepad_text_only\": \"ok\", \"notepad_both\": \"failed: SetIsBorderRequired failed: 不支持此接口 (0x80004002)\", \"explorer_screenshot\": \"failed: SetIsBorderRequired failed: 不支持此接口 (0x80004002)\" } ``` ### Suspected Cause Microsoft documents `GraphicsCaptureSession.IsBorderRequired` as introduced in Windows 10 version 2104 / build `10.0.20348.0`, API contract v12: https://learn.microsoft.com/en-us/uwp/api/windows.graphics.capture.graphicscapturesession.isborderrequired This repro machine is Windows 10 build `19045`, so `SetIsBorderRequired` appears to hit `E_NOINTERFACE` (`0x80004002`, no such interface supported). The capture helper seems to abort instead of continuing without border toggling. ### Expected Behavior On Windows builds where border toggling is unsupported, Computer Use should still capture screenshots if the underlying Windows Graphics Capture path is otherwise available. Suggested behavior: - Gate the border call with `ApiInformation.IsPropertyPresent(\"Windows.Graphics.Capture.GraphicsCaptureSession\", \"IsBorderRequired\")`, or an equivalent OS/API contract check. - If unsupported, skip `SetIsBorderRequired` and allow the default capture border behavior. - Alternatively, fail with a clear compatibility error such as: `Computer Use screenshots require Windows build 20348+ because border toggling is currently unconditional`. ### Impact This leaves Computer Use partially functional on Windows 10 22H2: - Working: app/window enumeration, activation, accessibility text, keyboard input. - Broken: screenshot-based UI inspection and accurate coordinate-based visual interaction. For users on Windows 10 build 19045, this means Computer Use cannot reliably operate visual apps even though non-visual operations work.", "url": "https://github.com/openai/codex/issues/25178", "createdAt": "2026-05-30T00:16:32Z", "updatedAt": "2026-08-12T22:45:03Z", "timestamp": "2026-08-12T22:45:03Z", "metrics": { "reactions": 13, "comments": 25 }, "labels": [ "bug", "windows-os", "app", "computer-use" ], "author": "Define1165250535", "state": "open", "assignees": [] }, { "id": "github:openai/codex:issue:25179", "source": "github", "group": "coding-agent-infrastructure", "project": "openai/codex", "kind": "issue", "title": "Codex app accumulates stale subagents in cache/UI and they cannot be closed reliably", "text": "### What version of the Codex App are you using (From “About Codex” dialog)? Versión 26.527.31326 (3390) ### What subscription do you have? Plus Plan ### What platform is your computer? Darwin 25.5.0 arm64 arm ### What issue are you seeing? ### Summary In a long-running Codex desktop session that uses many subagents, the app appears to accumulate stale subagent entries in the UI/cache. Completed or already-closed agents can remain visible, and closing them is not always reconciled cleanly with backend state. Over time, this makes it difficult to tell which subagents are actually still alive. ### Actual behavior After repeated spawn/complete/close cycles: - many old subagents remain visible long after completion - some close attempts return `shutdown` - some close attempts return `not found` - some agents appear completed but still remain listed - the visible subagent count can grow very large (in my case, 100+) ### Why this seems like an app bug This does not appear to be tied to a specific repo workflow. In my case, the stale subagent buildup was separate from the actual project state, and some close attempts returning `not found` suggest the app UI/cache and backend agent state can drift out of sync. ### Suggested debugging angles - UI cache vs backend state reconciliation for agent lifecycle - pruning/GC of completed subagents - handling of `close_agent` for already-completed or already-evicted agents - stale thread/agent handles remaining visible after shutdown - whether this only affects the UI list or also impacts future spawning ### Screenshot \"Image\" ### What steps can reproduce the bug? 1. Start a long Codex desktop session in a repo and use subagents heavily over time. 2. Spawn many subagents across multiple roles (for example: researcher, planner, reviewer, coder, trainer). 3. Let many of them finish normally. 4. Close completed subagents from the agent controls and/or via tool-driven close requests. 5. Continue spawning and closing more subagents in the same long-running session. 6. Revisit the subagent list/sidebar after enough cycles. ### Observed - many old subagents are still shown - some can no longer be closed cleanly - some close attempts return `not found` - some already-completed agents remain visible as if still retained in cache/UI - the visible count can grow very large (in my case, 100+) ### What is the expected behavior? Completed or explicitly closed subagents should no longer remain in the active visible subagent list. The app should reconcile UI state with backend state reliably: - if an agent is completed, it should appear as completed and be removable/archived cleanly - if an agent is closed, it should disappear from the live list or move to a clearly separate historical section - if an agent no longer exists, the UI should not keep showing it as lingering cached state Repeated spawn/complete/close cycles in a long session should not cause the visible subagent count to grow indefinitely with stale entries. ### Additional information _No response_", "url": "https://github.com/openai/codex/issues/25179", "createdAt": "2026-05-30T00:18:05Z", "updatedAt": "2026-08-12T13:48:53Z", "timestamp": "2026-08-12T13:48:53Z", "metrics": { "reactions": 1, "comments": 20 }, "labels": [ "bug", "app", "subagent" ], "author": "maxidiazbattan", "state": "open", "assignees": [], "change": "updated" }, { "id": "github:openai/codex:issue:25215", "source": "github", "group": "coding-agent-infrastructure", "project": "openai/codex", "kind": "issue", "title": "Long threads are unrecoverable when rollout JSONL grow beyond resume/list limits", "text": "## Summary A long-running `/goal` workflow can create a rollout JSONL that Codex Desktop can no longer safely resume or list, even though the workflow is behaving as designed. In this case, the thread was running normally under Codex Desktop with WSL enabled. The user paused the active goal to install a new Desktop update, then the updated app could not recover/resume the same thread because the local rollout had grown to about 3.06 GB. Small threads still loaded. The large goal thread repeatedly caused app-server failures and the UI fell back to `Codex app-server is not available` errors. This is not just a generic \"large file\" problem. `/goal` encourages exactly this usage pattern: an agent runs for a long time, loops through work, compacts context, spawns/reviews sub-work, and keeps appending local history. The model-visible context is bounded by compaction, but the persisted rollout file is not bounded or rotated. ## Environment - Codex Desktop: Windows Store app, observed after update to package family `OpenAI.Codex_26.527.x_x64__2p2nqsd0c76g0` - App-server: WSL/Linux Codex runtime launched by Desktop - Platform: Windows 11 x64 with Codex Desktop configured to run the agent in WSL - Subscription/model: ChatGPT-authenticated Codex Desktop, high-reasoning model - Local state paths, user names, and project names are intentionally redacted ## Reproduction shape 1. Use Codex Desktop on Windows with WSL-backed execution. 2. Start a long-running `/goal` workflow that performs repeated local work, review loops, sub-agent/tool loops, and iterative improvement passes. 3. Let the goal run for days, including many turns and multiple context compactions. 4. Pause the thread to install a Desktop update. 5. Reopen Codex Desktop and click/resume the same large thread. 6. The app-server crashes or becomes unavailable while hydrating/resuming the thread; a smaller thread still loads successfully. ## Local evidence from the affected profile The affected rollout file: ```text ~/.codex/sessions/2026/05/19/rollout--.jsonl size: 3,063,881,398 bytes ``` A rescue rollout built from the latest compacted checkpoint plus subsequent records was much smaller: ```text ~/.codex/rescue_rollouts/rollout-rescue--.jsonl size: 20,737,905 bytes lines: 382 records: session_meta=1, compacted=1, turn_context=1, event_msg=140, response_item=239 payloads included: thread_goal_updated=61, function_call=82, function_call_output=82, token_count=53, context_compacted=1 ``` The rescue was generated only after a full backup, and only by extracting the latest compaction boundary and following records. That is not a reasonable normal recovery path for a product feature. Desktop logs around the failing resume showed the large thread pending `thread/resume` and `thread/goal/get`, then the app-server becoming unavailable: ```text app_server_connection.closed code=9 ... transport=stdio fatal_error_broadcasted ... (code=9, signal=null) Request failed ... method=thread/resume ... error={\"code\":-32000,\"message\":\"Codex app-server is not available\"} Request failed ... method=thread/goal/get ... error={\"code\":-32000,\"message\":\"Codex app-server is not available\"} app_server_restart_recovery_failed ... errorMessage=\"Codex app-server is not available\" ``` Small-thread control test in the same app/profile loaded successfully, so the failure correlated with the large rollout/resume path rather than all Desktop startup. ## Source-level RCA Current `origin/main` at `00ca857d3ff6883b7334292d887601344e1bd029` still has full-file rollout hydration in key resume/list paths. `codex-rs/rollout/src/recorder.rs` reads the whole rollout into one string, then parses all lines into a `Vec`: ```rust pub async fn load_rollout_items( path: &Path, ) -> std::io::Result<(Vec, Option, usize)> { trace!(\"Resuming rollout from {path:?}\"); let text = tokio::fs::read_to_string(path).await?; ... let mut items: Vec = Vec::new(); for line in text.lines() { ... serde_json::from_str(line) ... ``` `codex-rs/thread-store/src/local/read_thread.rs` attaches history by loading the full rollout when `include_history=true`: ```rust let items = load_history_items(&path).await?; thread.history = Some(StoredThreadHistory { thread_id, items }); ``` `load_history_items()` delegates back to the full-file rollout loader: ```rust let (items, _, _) = RolloutRecorder::load_rollout_items(path).await?; ``` `codex-rs/app-server/src/request_processors/thread_processor.rs` resumes stored threads with history included: ```rust .read_stored_thread_for_resume(thread_id, path, /*include_history*/ true) ``` The `thread/turns/list` path also has a source comment acknowledging the scalability problem: ```rust // This API optimizes network transfer by letting clients page through a // thread's turns incrementally, but it still replays the entire rollout on // every request. Rollback and compaction events can change earlier turns, so // the server has to rebuild the full turn list until turn metadata is indexed // separately. ``` That design makes a 3 GB goal-created rollout inherently unsafe to hydrate. Even if context compaction keeps model context manageable, the local JSONL keeps growing and later resume/list paths still eagerly read and replay it. ## Expected behavior A `/goal` thread should remain recoverable after an app update if it was running normally before the update. At minimum: - Long-running `/goal` workflows should not create local session files that the product cannot reopen. - The app should not need to read a multi-GB rollout into one string to resume a thread or list turns. - If a thread is too large, Codex should show a recoverable per-thread error and offer a built-in compact/export/rescue path. - Goal state should be exportable/restorable from the latest compacted checkpoint without manual SQLite edits or JSONL surgery. - Auto-update should preflight active goal/session size and warn or create a safe checkpoint before replacing the running app. ## Actual behavior - The active goal thread became unrecoverable from Desktop after updating. - Resuming the large thread made the app-server unavailable while smaller threads loaded. - Recovering the work required unsupported manual steps: backing up the profile, finding the latest compaction boundary in a 3 GB JSONL, creating a reduced rescue rollout, and redirecting local thread metadata. - The recovered handoff is necessarily lower fidelity than a normal `/goal` resume because old pre-compaction records had to be dropped to keep the app usable. ## Suggested fixes 1. Stop using `read_to_string` for rollout hydration on resume/list paths. Stream parse JSONL, enforce record/byte caps, and avoid building a full `Vec` unless explicitly exporting. 2. Index turn metadata separately so `thread/turns/list` can page without replaying the full rollout on every request. 3. Make context compaction also produce a storage checkpoint. After a successful compaction, Codex should be able to prune or archive pre-compaction records while preserving an exportable full archive. 4. Add rollout rotation or hard warnings for `/goal` sessions. Example thresholds: 250 MB warning, 500 MB danger, 1 GB force checkpoint/export path. 5. Add a built-in \"recover from latest compaction\" command that creates a continuation thread or handoff without requiring direct DB edits. 6. During Desktop update, detect active goal threads and write a verified resume checkpoint before replacing the app/runtime. 7. Isolate per-thread failures. One oversized thread should not make the whole app-server or WSL-backed Desktop unusable. ## Related issues - #22004: Desktop main-process crash when rollout JSONL exceeds V8 max string length - #22991: app freezes with very large rollout/history JSONL - #21134: long active thread caused multi-GB app-server memory footprint - #22411: app-server loads/deserializes all session files for thread/list - #24510: long-running goal sessions emit many goal/progress events and stress local history/list paths - #24544: long sessions break `/goal` workflows via compaction failures - #21291: `/goal` and compaction behavior issue - #23340: `/goal` long-running loop caused runaway log growth - #23777: separate Windows Desktop WSL update failure that triggered this recovery attempt - #23053: update prompt should surface target versions/environment impact before users accept risky updates ## Privacy note I cannot attach the raw 3 GB rollout because it contains private local conversation history and project content. The sizes, record counts, method names, source paths, and stack-level RCA above are sanitized.", "url": "https://github.com/openai/codex/issues/25215", "createdAt": "2026-05-30T04:06:12Z", "updatedAt": "2026-08-13T15:33:30Z", "timestamp": "2026-08-13T15:33:30Z", "metrics": { "reactions": 1, "comments": 7 }, "labels": [ "bug", "windows-os", "context", "app", "session", "app-server", "performance" ], "author": "MisterRound", "state": "open", "assignees": [] }, { "id": "github:openai/codex:issue:25251", "source": "github", "group": "coding-agent-infrastructure", "project": "openai/codex", "kind": "issue", "title": "Codex Desktop: opening a large thread causes sustained 100%+ CPU until app restart", "text": "## Summary In Codex Desktop, opening a large existing conversation/thread can cause the Codex main process to stay at 100%+ CPU. Switching away to another conversation does not recover CPU usage; only fully restarting Codex clears it. ## Version - Codex Desktop version: `26.527.31326 (3390)` - Platform: macOS ## Reproduction 1. Start Codex Desktop. 2. Open a new/empty conversation: CPU remains normal. 3. Open an existing large conversation/thread. 4. Observe Codex main process CPU spikes to roughly `100%-200%`. 5. Switch to another conversation, including smaller conversations. 6. CPU remains high until Codex Desktop is fully restarted. ## Observed Details The problematic thread file is around `501 MB` and contains many saved tool results, not just regular chat text. Local inspection showed the size was mostly from persisted tool output records: - `function_call_output`: about `228 MB` - `mcp_tool_call_end`: about `171 MB` - assistant/user messages are much smaller by comparison Cleaning the local logs database did not fix the issue. The active thread itself was small in another test case, but opening this large thread first made the whole app remain slow until restart. Sampling the Codex Desktop main process while CPU was high showed activity concentrated around Electron/Node IPC paths, including `libuv stream -> JS callback -> Buffer/memmove` style work. The renderer also showed V8/renderer work during the spike. ## Expected Behavior Opening a large thread should not permanently peg CPU. If the large thread is expensive to load, Codex should either: - lazily load/virtualize thread history, - truncate or summarize persisted tool outputs in the UI, - avoid loading full tool output payloads unless expanded, - cancel/release parsing and rendering work when switching away from the thread, - and release memory/CPU pressure after navigating to another conversation. ## Actual Behavior After the large thread is opened once, CPU remains high even after switching away. A full app restart is required to recover. ## Impact Large long-running agent threads with many tool calls become effectively unsafe to open in Codex Desktop, because one open can make the whole app sluggish until restart.", "url": "https://github.com/openai/codex/issues/25251", "createdAt": "2026-05-30T09:40:12Z", "updatedAt": "2026-08-12T16:24:14Z", "timestamp": "2026-08-12T16:24:14Z", "metrics": { "reactions": 1, "comments": 6 }, "labels": [ "bug", "app", "session", "performance" ], "author": "ZhangChaoquan", "state": "open", "assignees": [] }, { "id": "github:openai/codex:issue:25453", "source": "github", "group": "coding-agent-infrastructure", "project": "openai/codex", "kind": "issue", "title": "Windows Codex Desktop spawns powershell.exe every second for full process polling, causing high CPU usage", "text": "### What version of the Codex App are you using (From “About Codex” dialog)? 26.527.31326 ### What subscription do you have? Pro ### What platform is your computer? Microsoft Windows NT 10.0.26200.0 x64 ### What issue are you seeing? Codex Desktop repeatedly spawns short-lived powershell.exe children under the Codex.exe GUI process to run full-machine CIM/WMI scans over Win32_Process and Win32_PerfFormattedData_PerfProc_Process. In a fresh 30.05s measurement, I observed 23 PowerShell/pwsh processes, approximately 0.77/sec, consuming about 48.95 CPU-seconds total. Roughly 1.6 logical cores of sustained load from this recent change to how Codex monitors apps. Confirmed child command examples: powershell.exe -NoProfile -NonInteractive -Command \"... Get-CimInstance Win32_Process | Select-Object ProcessId,ParentProcessId | ConvertTo-Json -Depth 2\" powershell.exe -NoProfile -NonInteractive -Command \"... Get-CimInstance Win32_PerfFormattedData_PerfProc_Process ... Get-CimInstance Win32_Process ... CommandLine,WorkingSetSize,...\" ### What steps can reproduce the bug? 019e7fe2-7262-7c50-bbbc-0a374d0db752 1. Run Codex Desktop on Windows. 2. Watch child processes under Codex.exe using Task Manager, System Informer, or Get-CimInstance Win32_Process. 3. When active, Codex.exe repeatedly spawns powershell.exe children running Get-CimInstance Win32_Process / Win32_PerfFormattedData_PerfProc_Process. I do not yet have a deterministic trigger; the loop appears intermittent or state-dependent but happens while conversations are ongoing. ### What is the expected behavior? Codex Desktop should not spawn PowerShell repeatedly for full-machine process polling. Process tracking should be throttled, non-overlapping, scoped to Codex-owned process trees, or implemented through a persistent/native helper. ### Additional information This appears to be Codex Desktop app behavior, not the standalone Codex CLI. The parent process is the packaged Windows app Codex.exe, and the likely source is Desktop process-manager code in app.asar. This did not happen before the updates at the end of last week (~28th/29th).", "url": "https://github.com/openai/codex/issues/25453", "createdAt": "2026-05-31T21:43:42Z", "updatedAt": "2026-08-13T01:59:42Z", "timestamp": "2026-08-13T01:59:42Z", "metrics": { "reactions": 7, "comments": 25 }, "labels": [ "bug", "windows-os", "app", "performance" ], "author": "jrf1001", "state": "open", "assignees": [] }, { "id": "github:openai/codex:issue:25541", "source": "github", "group": "coding-agent-infrastructure", "project": "openai/codex", "kind": "issue", "title": "Codex Desktop (Windows): UI-archived conversations reappear in active sidebar after refresh, and archive triggers flashing terminal cleanup", "text": "### What version of the Codex App are you using (From \"About Codex\" dialog)? Observed on a Windows desktop install whose shipped frontend bundle is: - `openai.chatgpt-26.325.31654-win32-x64` Affected local bundle paths: - `C:\\Users\\q1371\\.antigravity\\extensions\\openai.chatgpt-26.325.31654-win32-x64\\webview\\assets\\app-server-manager-hooks-XL0eRatK.js` - `C:\\Users\\q1371\\.antigravity-ide\\extensions\\openai.chatgpt-26.325.31654-win32-x64\\webview\\assets\\app-server-manager-hooks-XL0eRatK.js` ### What subscription do you have? Pro / paid account context on the reporting machine. ### What platform is your computer? Windows 11 x64 ### What issue are you seeing? Archiving conversations from the official Codex Desktop sidebar appears to succeed briefly, but after a later refresh / reconciliation cycle the archived conversations reappear in the active sidebar list. At the same time, the archive action on Windows frequently causes visible flashing terminal windows, which strongly suggests that the archive UI path is dispatching unnecessary worktree cleanup during archive. This is not just a one-off local DB inconsistency or a direct-SQL repro. The problem reproduces when the user archives threads through the normal Desktop UI, then waits for the app to refresh/reconcile its recent-thread list. ### What steps can reproduce the bug? 1. Open Codex Desktop on Windows with many existing local conversations in the sidebar. 2. Archive multiple conversations from the normal sidebar UI. 3. Confirm they disappear initially. 4. Keep using the app or wait for the next refresh/reconciliation pass. 5. Observe that the previously archived conversations reappear in the active sidebar list. 6. During archive operations, observe frequent short-lived flashing terminal windows on Windows. ### What is the expected behavior? 1. A conversation archived from the Desktop UI should remain hidden from the active sidebar list after refresh/reconciliation unless the user explicitly unarchives it. 2. Archiving should not trigger visible terminal flashes or unrelated worktree cleanup on Windows. ### Additional information I inspected the shipped desktop frontend bundle and found two likely client-side causes. #### 1. Archive UI dispatch defaults `cleanupWorktree` to true The shipped bundle contains logic equivalent to: ```js function gp(e,t={}){return t.cleanupWorktree!==!1&&(e==null||lp(e.source)==null)} ... dispatchMessage(\"archive-thread\", { hostId, conversationId, cwd, cleanupWorktree: r.cleanupWorktree !== false, }) ``` This matches the Windows symptom where archiving causes visible flashing terminal windows. In a local hotfix, forcing `cleanupWorktree: false` stopped that flashing behavior. #### 2. The frontend maintains archive suppression state, but recent-sidebar readers do not consistently honor it after refresh The same bundle maintains a local set named: ```js suppressedArchivedConversationIds ``` However, the recent/sidebar read paths rebuild from `recentConversationIds` and do not consistently filter archived-suppressed IDs when rendering recent conversations and related derived state. The most relevant readers are equivalent to: - `getRecentConversations()` - `getRecentConversationCwds()` - `getUnreadLocalConversationCount()` - `getHasInProgressLocalConversation()` In a local hotfix, filtering these readers by `suppressedArchivedConversationIds.has(conversationId)` prevented archived conversations from reappearing in the active sidebar after refresh. #### Why this issue is likely related to, but distinct from, existing reports - Related to [#23851](https://github.com/openai/codex/issues/23851), which reports archive state being reset during reconciliation. That report uses a direct DB repro; this report confirms that the same family of problem is reachable through the official Desktop UI archive flow. - Related to [#20317](https://github.com/openai/codex/issues/20317) and several other archive/session/sidebar bugs, but this specific report adds a deterministic frontend-side explanation for both: - archived threads reappearing in the active sidebar - archive causing terminal flashes on Windows #### Suggested fix 1. Do not default Desktop UI archive dispatches to `cleanupWorktree: true`. 2. Ensure all recent/sidebar rendering and derived-state readers consistently exclude locally suppressed archived conversation IDs after archive succeeds. 3. Add regression coverage for: - archive from Desktop UI, refresh sidebar, archived thread stays hidden - bulk archive from Desktop UI, refresh sidebar, archived threads stay hidden - archive on Windows does not trigger visible terminal cleanup windows This looks like a Desktop frontend reconciliation bug rather than a machine-specific corruption issue.", "url": "https://github.com/openai/codex/issues/25541", "createdAt": "2026-06-01T07:30:44Z", "updatedAt": "2026-08-13T12:15:20Z", "timestamp": "2026-08-13T12:15:20Z", "metrics": { "reactions": 1, "comments": 3 }, "labels": [ "bug", "windows-os", "app", "session" ], "author": "biggameking", "state": "open", "assignees": [] }, { "id": "github:openai/codex:issue:25647", "source": "github", "group": "coding-agent-infrastructure", "project": "openai/codex", "kind": "issue", "title": "Browser skill is mounted in CLI TUI even when no in-app browser backend is available", "text": "### What issue are you seeing? When using the Codex CLI TUI directly, the bundled Browser / in-app browser skill is still mounted and advertised even though there is no Codex desktop app in-app browser backend available for the session. This makes `@Browser` / `$browser` look usable in the CLI TUI, but the Browser runtime cannot discover any browser backend: ```text agent.browsers.list() => [] agent.browsers.get(\"iab\") => Browser is not available: iab ``` The confusing part is that the skill itself is present and its `browser-client.mjs` can be loaded, so the agent spends time trying the Browser bootstrap path before discovering that no `iab` backend exists. In a pure CLI TUI session, there is no in-app browser pane for the skill to attach to. ### Environment - Codex CLI: `codex-cli 0.135.0` - Platform: macOS 26.5 / Darwin 25.5.0 arm64 - Session type: CLI TUI launched directly from a terminal, not the Codex desktop app - Browser plugin cache exists locally under `~/.codex/plugins/cache/openai-bundled/browser/...` ### Steps to reproduce 1. Launch `codex` as the CLI TUI directly from a terminal. 2. Ask Codex to use `$browser` / `@Browser` for a quick in-app browser check. 3. Observe that the Browser skill is mounted and the agent attempts to use the Browser plugin. 4. The runtime reports no available browser backend, e.g. `agent.browsers.list()` returns `[]` and `agent.browsers.get(\"iab\")` fails. ### Expected behavior For CLI TUI sessions that are not attached to a Codex desktop app in-app browser backend, either: - do not mount/advertise the in-app Browser skill at all, or - expose it as unavailable with a clear immediate message such as: `The in-app browser requires the Codex desktop app and is unavailable in CLI TUI sessions.` ### Actual behavior The Browser skill is mounted and looks available, but no usable browser backend exists. This makes the failure look like a broken Browser plugin, missing extension, or IAB discovery regression, when the real issue is that the CLI TUI has no in-app browser surface. ### Why this matters It causes avoidable confusion between three separate cases: - Codex desktop app in-app browser (`iab` backend) - Codex Chrome extension / real browser control - CLI TUI with no browser backend For users who explicitly do not want the Chrome extension and only want the in-app browser, the current CLI TUI behavior suggests that in-app browser support should work when it cannot.", "url": "https://github.com/openai/codex/issues/25647", "createdAt": "2026-06-01T16:52:05Z", "updatedAt": "2026-08-13T14:20:28Z", "timestamp": "2026-08-13T14:20:28Z", "metrics": { "reactions": 4, "comments": 4 }, "labels": [ "bug", "TUI", "skills", "browser" ], "author": "JoeRoddy", "state": "open", "assignees": [] }, { "id": "github:openai/codex:issue:25719", "source": "github", "group": "coding-agent-infrastructure", "project": "openai/codex", "kind": "issue", "title": "Codex Desktop for macOS repeatedly triggers `syspolicyd` / `trustd` CPU and memory runaway", "text": "### What version of the Codex App are you using (From “About Codex” dialog)? Codex Desktop: 26.527.60818 Codex build: 3437 ### What subscription do you have? plus ### What platform is your computer? Darwin 25.5.0 arm64 arm ### What issue are you seeing? Codex Desktop for macOS triggers a persistent macOS Gatekeeper/SystemPolicy loop after launch. With Codex closed, the system is quiet. As soon as Codex Desktop is opened, `/usr/libexec/syspolicyd` rises to very high CPU usage and grows to multiple GB of RAM. This happens even after replacing Codex with a freshly downloaded DMG build. This appears related to Codex Desktop launching or validating its bundled/helper components, including `Codex Computer Use`, but the problem also reproduces after user-facing Browser/hotkey/notify settings were disabled. ### What steps can reproduce the bug? ## Reproduction steps 1. Boot macOS normally. 2. Ensure Codex Desktop is closed. 3. Observe Activity Monitor: CPU is normal. 4. Run: ```bash sudo killall -9 syspolicyd trustd ``` 5. Confirm CPU is still normal. 6. Open Codex Desktop. 7. Observe `syspolicyd` rising to very high CPU and memory usage. The same pattern was observed after manually replacing Codex with the latest freshly downloaded DMG build. ### What is the expected behavior? _No response_ ### Additional information # Bug Report: Codex Desktop for macOS repeatedly triggers `syspolicyd` / `trustd` CPU and memory runaway ## Summary Codex Desktop for macOS triggers a persistent macOS Gatekeeper/SystemPolicy loop after launch. With Codex closed, the system is quiet. As soon as Codex Desktop is opened, `/usr/libexec/syspolicyd` rises to very high CPU usage and grows to multiple GB of RAM. This happens even after replacing Codex with a freshly downloaded DMG build. This appears related to Codex Desktop launching or validating its bundled/helper components, including `Codex Computer Use`, but the problem also reproduces after user-facing Browser/hotkey/notify settings were disabled. ## Environment ```text Device: Apple Silicon MacBook Air, M5 macOS: 26.5 Build: 25F71 Codex Desktop: 26.527.60818 Codex build: 3437 Timezone: Europe/Rome Date observed: 2026-06-01 / 2026-06-02 ``` Previous Codex version also affected: ```text Codex Desktop: 26.527.31326 Build: 3390 ``` ## Main symptom When Codex is closed: ```text CPU usage is normal. Activity Monitor is quiet. syspolicyd / trustd are not consuming significant resources. ``` When Codex is opened: ```text /usr/libexec/syspolicyd immediately rises to very high CPU usage. CPU observed: approximately 125% to 200%. Memory observed: over 8 GB RSS in one run. trustd also becomes active. ``` Example captured after launching Codex build 3437: ```text %CPU PID %MEM RSS COMMAND 125.7 29702 34.0 8549776 /usr/libexec/syspolicyd 11.3 29728 3.0 756064 /Applications/Codex.app/Contents/Resources/codex app-server --analytics-default-enabled 11.1 29701 1.9 471728 /Applications/Codex.app/Contents/MacOS/Codex 6.5 29699 0.1 16800 /usr/libexec/trustd ``` ## User-visible Gatekeeper dialog The user repeatedly sees: ```text \"Codex Computer Use\" is damaged and can't be opened. You should move it to the Trash. This file was downloaded on an unknown date. ``` The app named in the dialog is: ```text /Users/mgair/.codex/computer-use/Codex Computer Use.app ``` ## Important verification The affected helper app does not appear to be actually corrupt. It was checked locally: ```text codesign verification: valid on disk Developer ID: OpenAI OpCo, LLC TeamIdentifier: 2DC432GLL2 Notarization ticket: stapled ``` `cmux.app`, another unrelated notarized app, is accepted by Gatekeeper when `syspolicyd` is not wedged: ```text /Applications/cmux.app: accepted source=Notarized Developer ID ``` This suggests the issue is not a generally unsigned or damaged app problem. It looks like `syspolicyd` enters a bad state after Codex Desktop starts. ## Reproduction steps 1. Boot macOS normally. 2. Ensure Codex Desktop is closed. 3. Observe Activity Monitor: CPU is normal. 4. Run: ```bash sudo killall -9 syspolicyd trustd ``` 5. Confirm CPU is still normal. 6. Open Codex Desktop. 7. Observe `syspolicyd` rising to very high CPU and memory usage. The same pattern was observed after manually replacing Codex with the latest freshly downloaded DMG build. ## Workarounds attempted ### 1. Increase open file limit The system `maxfiles` limit was increased: ```text maxfiles 65536 unlimited ``` This did not fix the issue. ### 2. Disable Codex Computer Use / Browser / hotkey hooks in user config Current config state: ```toml notify = [] [plugins.\"browser@openai-bundled\"] enabled = false ``` Current keybindings: ```json [] ``` Current global hotkey state: ```json \"globalDictationToggleHotkey\": null \"appshotHotkey\": null ``` The config files were temporarily protected from silent rewrites using `uchg`. Despite this, after launching Codex Desktop, these processes still appeared: ```text /Users/mgair/.codex/computer-use/Codex Computer Use.app/Contents/MacOS/SkyComputerUseService /Users/mgair/.codex/computer-use/Codex Computer Use.app/Contents/SharedSupport/SkyComputerUseClient.app/.../SkyComputerUseClient turn-ended --previous-notify [] ``` This suggests Codex Desktop may be launching `Codex Computer Use` outside the user-visible config path, or the desktop process may have a separate internal integration path. ### 3. In-app update The in-app Sparkle update previously failed: ```text SUSparkleErrorDomain Code=4005 \"An error occurred while starting the installer. Please try again later.\" ``` Manual DMG replacement succeeded, but did not resolve the issue. ## Additional concern One stale `SkyComputerUseClient turn-ended` process was observed with a very large serialized conversation payload in its command-line arguments. That command line appeared to include extensive thread context. This may be relevant if the helper is being repeatedly assessed or launched with very large arguments. For privacy, the full command line is not included here, but it was clearly visible in `pgrep -alf` output. ## Expected behavior Opening Codex Desktop should not cause: - `syspolicyd` to consume 100-200% CPU. - `syspolicyd` to grow to multi-GB memory use. - Gatekeeper to show `\"Codex Computer Use\" is damaged`. - unrelated notarized apps to become hard to open while `syspolicyd` is wedged. ## Actual behavior Codex launch reliably causes `syspolicyd` and sometimes `trustd` to spike. Closing Codex and killing `syspolicyd` / `trustd` calms the system. Reopening Codex reproduces the issue. ## User impact This caused hours of troubleshooting, repeated reboots including Safe Mode attempts, broken/blocked app launches while `syspolicyd` was wedged, and significant Codex usage spent diagnosing the Codex Desktop bug itself. ## Update: Reinstall / macOS 26.5.1 Did Not Fix It The user reinstalled/updated macOS and retested. Current system after reinstall/update: ```text macOS: 26.5.1 Build: 25F80 Codex Desktop: 26.527.60818 Codex build: 3437 ``` Result: the issue still reproduces. Before launching Codex, `fileproviderd` was already using high CPU, likely due to iCloud/File Provider resync after the reinstall. However, `syspolicyd` spiked specifically after Codex was launched. Example after launching Codex on macOS 26.5.1: ```text %CPU PID %MEM RSS COMMAND 106.3 668 4.6 1164208 /usr/libexec/syspolicyd 89.7 1190 0.5 120336 /System/Library/PrivateFrameworks/FileProvider.framework/Support/fileproviderd 11.4 2827 1.9 488912 /Applications/Codex.app/Contents/MacOS/Codex 7.0 601 0.1 19808 /usr/libexec/trustd 0.0 3097 0.5 114592 /Users/mgair/.codex/computer-use/Codex Computer Use.app/Contents/MacOS/SkyComputerUseService ``` Important: the Codex config files still showed: ```text notify = [] Browser plugin disabled keybindings = [] globalDictationToggleHotkey = null appshotHotkey = null config files protected with uchg ``` Despite that, Codex Desktop still launched: ```text /Users/mgair/.codex/computer-use/Codex Computer Use.app/Contents/MacOS/SkyComputerUseService ``` Additional observation on macOS 26.5.1: the `syspolicyd` CPU usage is not just a short startup spike. It can drop temporarily and then rise again. One later sample showed: ```text %CPU PID %MEM RSS ELAPSED COMMAND 181.6 668 7.4 1858064 19:03 /usr/libexec/syspolicyd ``` At that later point, the `SkyComputerUseService` process was no longer visible in the process list, but `syspolicyd` was still consuming very high CPU. This suggests the system policy loop may continue after the helper process exits or disappears. Conclusion after this update: the issue is unlikely to be local corruption of Gatekeeper/SystemPolicy databases. It appears to be a reproducible Codex Desktop/macOS 26.5.x integration problem, and Codex Desktop appears to launch `Codex Computer Use` even when the visible user config disables the related hooks. ## Request Please escalate this to the Codex Desktop/macOS team. Please also consider a goodwill account credit, usage refund, or temporary upgrade for the affected user, since substantial paid usage was consumed diagnosing what appears to be a Codex Desktop/macOS integration bug rather than the user's requested work. Suggested account-facing wording: ```text I spent substantial paid Codex usage diagnosing a reproducible Codex Desktop bug on macOS where launching Codex causes syspolicyd/trustd CPU and memory runaway. Please consider restoring the consumed usage or providing a temporary upgrade/credit while this is investigated. ``` ## Attachments / useful local file Detailed local troubleshooting notes: ```text /Users/mgair/Documents/New project/Codex_Gatekeeper_Workaround_2026-06-01.md ```", "url": "https://github.com/openai/codex/issues/25719", "createdAt": "2026-06-01T23:59:29Z", "updatedAt": "2026-08-13T08:23:26Z", "timestamp": "2026-08-13T08:23:26Z", "metrics": { "reactions": 445, "comments": 84 }, "labels": [ "bug", "app", "computer-use", "performance" ], "author": "energissimo-mg", "state": "open", "assignees": [] }, { "id": "github:openai/codex:issue:25810", "source": "github", "group": "coding-agent-infrastructure", "project": "openai/codex", "kind": "issue", "title": "Windows Desktop: new threads/handoffs persist as on-request/workspaceWrite instead of inheriting visible Full Access state", "text": "## Summary On Windows Codex Desktop, newly created threads can persist as `approvalPolicy = on-request` / `sandboxPolicy.type = workspaceWrite` even when the user workflow appears to be operating in a Full Access-like mode. This is reproducible with: - ordinary fresh test threads - handoff-created threads and does **not** require Goal auto-continuation. ## Environment - Codex Desktop app: `OpenAI.Codex_26.527.7698.0_x64__2p2nqsd0c76g0` - Platform: Windows ## Expected If the user has switched into a Full Access-like mode in the app, newly created threads should inherit that mode consistently, or the UI should clearly indicate that new threads will still be created with approval prompts. ## Actual Newly created threads are persisted as: - `approvalPolicy = on-request` - `approvalsReviewer = guardian_subagent` - `sandboxPolicy.type = workspaceWrite` This then causes approval prompts to originate from those new threads. ## Repro 1. Open Codex Desktop on Windows. 2. Work in a thread until the UI/workflow suggests Full Access-like behavior is active. 3. Create a new thread from that session, or create a handoff into a new thread. 4. Let the new thread do almost nothing, e.g. only answer once with a short reply. 5. Inspect persisted thread state in `C:\\Users\\강인철\\.codex\\.codex-global-state.json`. 6. Observe that the new thread is stored as `on-request / guardian_subagent / workspaceWrite`. ## Concrete repro evidence Host-level persisted mode in app state: - `agent-mode-by-host-id.local = guardian-approvals` - `preferred-non-full-access-agent-mode-by-host-id.local = guardian-approvals` Fresh / recent threads created during reproduction: - current thread `019e866c-0a1c-7601-a60c-686b686bcc5c` -> `on-request / guardian_subagent / workspaceWrite` - test thread `019e8764-2aa9-73d2-9b3d-87ecb202af5a` -> `on-request / guardian_subagent / workspaceWrite` - test thread `019e8765-f908-7410-b44d-443df7934c73` -> `on-request / guardian_subagent / workspaceWrite` - test thread `019e877d-fb12-7683-8033-3f909b8ca714` -> `on-request / guardian_subagent / workspaceWrite` - handoff-derived thread `019e8689-b909-7ed1-a141-d0b3323a21cf` -> `on-request / guardian_subagent / workspaceWrite` Additional pattern: - among currently stored thread states on this machine, only **1** thread had `approvalPolicy = never` - **60** threads had `approvalPolicy = on-request` ## Why this seems like a bug This does not look like a one-off stuck thread. It looks like one of: - thread creation is not inheriting the currently visible Full Access selection - host-level permission mode is not being committed correctly before thread creation - handoff/new-thread creation is using a different policy source than the visible UI state - the app is exposing a misleading Full Access state to the user while still creating threads in guardian-approvals mode ## Related This may be related to, but broader than, the behavior discussed in #24300. I also added Windows reproduction details there in a comment: - https://github.com/openai/codex/issues/24300#issuecomment-4600486234", "url": "https://github.com/openai/codex/issues/25810", "timestamp": "2026-08-12T12:57:23Z", "metrics": { "reactions": 4, "comments": 11 }, "labels": [ "bug", "windows-os", "sandbox", "app", "session" ], "author": "andrewkangkr", "assignees": [], "change": "new" }, { "id": "github:openai/codex:issue:26250", "source": "github", "group": "coding-agent-infrastructure", "project": "openai/codex", "kind": "issue", "title": "Fix RTL/LTR text rendering for mixed Arabic and English in Codex", "text": "### What version of the Codex App are you using (From “About Codex” dialog)? 26.601.21317 ### What subscription do you have? Plus ### What platform is your computer? MacOS ### What issue are you seeing? I’m experiencing a bidirectional text rendering issue in Codex. When I write Arabic text with an English word in the middle, the word order is displayed incorrectly. This only happens in Codex; the same mixed Arabic/English text appears correctly in other apps and browsers. Please improve RTL/LTR bidirectional text handling in Codex so Arabic sentences remain in the correct order when they contain English words or numbers. ### What steps can reproduce the bug? 1. Open Codex. 2. Start a new conversation or use an existing one. 3. Type an Arabic sentence that includes an English word in the middle, for example: \"لاحظ لما اكتب اي كلمة English وبعدها كلام بالعربي\" 4. Send the message or view it in the input/conversation area. 5. Notice that the word order is displayed incorrectly compared with other apps or browsers. ### What is the expected behavior? Arabic text should keep the correct RTL word order even when it contains English words or numbers. For example, this sentence should display in the same order as typed: \"لاحظ لما اكتب اي كلمة English وبعدها كلام بالعربي\" The mixed Arabic/English text should render correctly in Codex, just like it does in other apps and browsers. ### Additional information This issue appears to be specific to Codex. The same mixed Arabic/English text displays correctly in other apps and browsers. The problem affects Arabic RTL text when it contains LTR content such as English words or numbers. Screenshots can be provided to show the incorrect word order.", "url": "https://github.com/openai/codex/issues/26250", "createdAt": "2026-06-03T20:58:26Z", "updatedAt": "2026-08-13T05:48:30Z", "timestamp": "2026-08-13T05:48:30Z", "metrics": { "reactions": 0, "comments": 15 }, "labels": [ "bug", "app" ], "author": "Yazeed-A-H", "state": "open", "assignees": [] }, { "id": "github:openai/codex:issue:26279", "source": "github", "group": "coding-agent-infrastructure", "project": "openai/codex", "kind": "issue", "title": "Feature request: allow folding verbose MCP tool result bodies in the Codex CLI TUI", "text": "### What variant of Codex are you using? CLI ### What feature would you like to see? I would like the Codex CLI TUI to support folding or hiding verbose MCP tool result bodies in the main conversation history, while preserving the full result for the model and for explicit transcript inspection. Today, Codex CLI TUI renders MCP tool result text directly in the conversation history after each MCP call. For tools that return file contents, the visible transcript can be dominated by tool result bodies: ```text • Called jetbrains-mcp.read_file(...) └ L1: ... L2: ... ... ``` This makes it difficult to read the assistant's higher-level messages. The issue is especially visible when the agent must load several skill, instruction, or project context files: those reads are legitimate and should not be artificially shortened, but their result bodies still flood the visible TUI history. Reasonable designs: - Default collapsed MCP result body: ```text • Called jetbrains-mcp.read_file(...) 58 lines, 9.2 KB Press or open transcript to view result ``` - Config option, for example: ```toml [tui] fold_mcp_tool_results = \"auto\" # auto | always | never mcp_tool_result_preview_lines = 1 ``` - Per-cell expand/collapse interaction in the transcript/history view. Important distinction: this should be a display feature. It should not truncate or hide tool results from the model context, and it should not encourage agents to under-read required skill/instruction files. ### Additional information Local environment where this was observed: ```text Codex CLI: 0.135.0 Platform: Windows 11 Professional x64 Terminal: Windows Terminal / PowerShell MCP server example: JetBrains MCP through stdio router ``` Reproduction outline: 1. Configure any MCP server that exposes a file-reading tool. A JetBrains MCP server is one example. 2. Start Codex CLI in TUI mode. 3. Ask the assistant to read a file through MCP, for example a skill or project instruction file. 4. Observe the conversation history after the MCP call. Source check against current main suggests this is not currently configurable: - `McpToolCallCell::display_lines()` renders `CallToolResult.content` directly into history detail lines. - `TOOL_CALL_MAX_LINES` limits visible result height but still shows the body by default. - `/raw` / `tui.raw_output_mode` is for copy-friendly transcript selection and does not solve this compact-history use case. This issue is about TUI readability and operator ergonomics, not MCP correctness.", "url": "https://github.com/openai/codex/issues/26279", "createdAt": "2026-06-04T01:10:59Z", "updatedAt": "2026-08-13T08:01:23Z", "timestamp": "2026-08-13T08:01:23Z", "metrics": { "reactions": 2, "comments": 4 }, "labels": [ "enhancement", "windows-os", "mcp", "TUI" ], "author": "sandynz", "state": "open", "assignees": [] }, { "id": "github:openai/codex:issue:26308", "source": "github", "group": "coding-agent-infrastructure", "project": "openai/codex", "kind": "issue", "title": "Codex Desktop ignores project-local model_catalog_json for fresh project threads", "text": "This bug report was written by Codex. ## Summary Codex Desktop appears to ignore a trusted project's `.codex/config.toml` `model_catalog_json` setting when creating a fresh project thread, while the CLI/debug path from the same cwd respects it. This prevents project-local custom model catalogs from working in Desktop, including per-model `base_instructions` / `model_messages.instructions_template` changes. ## Environment - OS: Windows - Codex Desktop fresh-thread originator in rollout: `Codex Desktop` - Desktop rollout `cli_version`: `0.136.0-alpha.2` - Desktop rollout source: `vscode` - CLI test originator in rollout: `codex-tui` - CLI test `cli_version`: `0.130.0-alpha.5` - Project cwd: `F:\\Projects\\_sandbox` ## Project Config Project-local config was created at: ```toml # F:\\Projects\\_sandbox\\.codex\\config.toml model_catalog_json = \"model-catalog.json\" ``` The referenced catalog exists at: ```text F:\\Projects\\_sandbox\\.codex\\model-catalog.json ``` The catalog was generated from the normal Codex model cache, but with the trailing `## Intermediary updates` section removed from both fields for every model entry: - `base_instructions` - `model_messages.instructions_template` This was done for all cached models: - `gpt-5.5` - `gpt-5.4` - `gpt-5.4-mini` - `gpt-5.3-codex-spark` - `codex-auto-review` ## Expected Behavior When creating a fresh Codex Desktop thread in trusted project `F:\\Projects\\_sandbox`, Desktop should load the project-local `.codex/config.toml`, resolve `model_catalog_json = \"model-catalog.json\"` relative to the project `.codex` directory, and use the corresponding catalog entry for the selected model. In this test, a fresh Desktop thread using `gpt-5.5` should have received base instructions without `## Intermediary updates`. ## Actual Behavior Fresh Codex Desktop project threads continued to receive base instructions containing `## Intermediary updates`, despite the project-local catalog having that section removed from both `base_instructions` and `model_messages.instructions_template`. Two Desktop test threads showed the issue: ```text codex://threads/019e90cd-abd3-7f73-99fe-2f9015a40047 codex://threads/019e90d5-47f0-7e81-861f-abe3778312d8 ``` Inspection of the persisted rollout for `019e90d5-47f0-7e81-861f-abe3778312d8` showed: ```text Cwd: F:\\Projects\\_sandbox Originator: Codex Desktop Source: vscode cli_version: 0.136.0-alpha.2 SessionHasUpdates: True ProjectBaseHasUpdates: False ProjectTemplateHasUpdates: False GlobalBaseHasUpdates: True GlobalTemplateHasUpdates: True ``` The Desktop session base instructions still contained the stripped section, indicating Desktop did not use the project-local catalog. ## CLI Control Test Running the CLI from the same cwd did respect the project-local catalog. CLI test thread: ```text codex://threads/019e90dd-884f-7b01-b969-988e3e9f1a69 ``` Inspection of that rollout showed: ```text Cwd: F:\\Projects\\_sandbox Originator: codex-tui Source: cli cli_version: 0.130.0-alpha.5 SessionHasUpdates: False SessionHasUpdateAsYouGo: False ProjectBaseHasUpdates: False ProjectTemplateHasUpdates: False GlobalBaseHasUpdates: True GlobalTemplateHasUpdates: True ``` `codex debug models` from `F:\\Projects\\_sandbox` also loaded the project-local catalog and reported that both `base_instructions` and `model_messages.instructions_template` no longer contained `## Intermediary updates`. ## Why This Matters The documented project-local `.codex/config.toml` config path is useful for repo-specific model catalog overrides, including per-model base-instruction tuning. It currently appears to work in CLI/debug but not in Desktop project thread creation. This makes it difficult to use project-local model catalog behavior in Desktop without changing global `C:\\Users\\\\.codex\\config.toml`, which is too broad for repo-specific experiments. ## Notes One remaining initial progress note in the CLI test was expected because a separate injected AGENTS wrapper rule said: ```text For multi-step or tool-heavy work, start with a short progress note stating the first step. ``` That is separate from the model catalog behavior. The important distinction is that the CLI session did not receive the stripped `## Intermediary updates` model-base section, while Desktop did.", "url": "https://github.com/openai/codex/issues/26308", "createdAt": "2026-06-04T04:29:58Z", "updatedAt": "2026-08-13T11:10:31Z", "timestamp": "2026-08-13T11:10:31Z", "metrics": { "reactions": 1, "comments": 3 }, "labels": [ "bug", "windows-os", "app", "config" ], "author": "Vadevious", "state": "open", "assignees": [] }, { "id": "github:openai/codex:issue:26534", "source": "github", "group": "coding-agent-infrastructure", "project": "openai/codex", "kind": "issue", "title": "Add a web-based Codex plugin marketplace and let Codex submit feedback with user approval", "text": "### What variant of Codex are you using? mac IDE ### What feature would you like to see? no-active-thread-019e9628-47dd-7210-92d8-839be056cc1f Feedback I have two related requests: 1. Provide an official web-based entry point for the Codex plugin marketplace Today, plugins are mainly browsed inside the Codex app. However, the desktop app is not convenient to zoom or browse on a large screen, which makes it harder to review plugin lists, compare capabilities, read installation instructions, understand permissions, and share plugin links. The plugin ecosystem needs a better public discovery surface, similar to the App Store or Chrome Web Store. A web-based plugin directory could support search, filtering, categories, plugin detail pages, example prompts, permission details, screenshots, changelogs, official vs. third-party labels, installation instructions, and shareable links. 2. Allow Codex to submit product feedback or issue reports directly, with explicit user approval Users often describe product feedback clearly inside a Codex conversation, but then still need to find the feedback entry point, copy the text, paste it somewhere else, and submit it manually. That extra step means a lot of valuable feedback dies at the last inch. It would be helpful if Codex could, after explicit user confirmation, submit the current product suggestion, bug report, or UX issue directly to OpenAI’s feedback system. Ideally, Codex would return a feedback ID or submission status after submitting. Why this matters For the plugin ecosystem to grow, users need an easier way to discover, compare, and share plugins. For the product to improve quickly, OpenAI needs a lower-friction path for users to submit real feedback. When plugin discovery and feedback submission both require extra in-app steps, many users will simply give up. This is especially true because people often assume “someone else must have already reported this,” which can cause obvious issues to receive weaker feedback signals than they deserve. One-sentence summary Please add an official web-based Codex plugin marketplace, and allow Codex to submit feedback directly after explicit user approval, so plugin discovery and feedback reporting both become much lower-friction. ### Additional information _No response_", "url": "https://github.com/openai/codex/issues/26534", "createdAt": "2026-06-05T05:04:50Z", "updatedAt": "2026-08-13T14:20:53Z", "timestamp": "2026-08-13T14:20:53Z", "metrics": { "reactions": 1, "comments": 1 }, "labels": [ "enhancement", "codex-web", "skills" ], "author": "47code", "state": "open", "assignees": [] }, { "id": "github:openai/codex:issue:26613", "source": "github", "group": "coding-agent-infrastructure", "project": "openai/codex", "kind": "issue", "title": "Codex Desktop on Windows flashes visible PowerShell/console windows during background process polling", "text": "# Bug report: Codex Desktop on Windows flashes visible PowerShell/console windows during background process polling ## Summary Codex Desktop on Windows repeatedly launches short-lived `powershell.exe` processes for background process inspection. These processes are created with a visible console window, causing black terminal windows to flash on screen during normal use, even when the user is not explicitly running a command. This is disruptive and alarming because it looks like an unknown terminal or malware process briefly opening and closing. ## Environment - OS: Windows - Codex Desktop version: `OpenAI.Codex_26.602.3474.0_x64__2p2nqsd0c76g0` - Codex CLI helper path observed: `C:\\Users\\Administrator\\AppData\\Local\\OpenAI\\Codex\\bin\\fb2111b91430cb17\\codex.exe` - Shell observed: `C:\\WINDOWS\\System32\\WindowsPowerShell\\v1.0\\powershell.exe` - User's default daily terminal: Warp - Windows Terminal delegation was removed from: `HKCU\\Console\\%%Startup` but visible black console flashes still occurred. ## Evidence Multiple Windows Event Log entries show Codex-spawned PowerShell processes with commands like: ```powershell powershell.exe -NoProfile -NonInteractive -Command \"$ErrorActionPreference = 'Stop'; Get-CimInstance Win32_Process | Select-Object ProcessId,ParentProcessId | ConvertTo-Json -Depth 2\" ``` and: ```powershell powershell.exe -NoProfile -NonInteractive -Command \"$ErrorActionPreference = 'Stop'; $cpuByPid = @{}; Get-CimInstance Win32_PerfFormattedData_PerfProc_Process | ForEach-Object { $cpuByPid[[int]$_.IDProcess] = [double]$_.PercentProcessorTime }; Get-CimInstance Win32_Process -Filter ... | Select-Object ProcessId,ParentProcessId,CommandLine,WorkingSetSize,... | ConvertTo-Json -Depth 2\" ``` Observed parent process: ```text ParentProcessId: 14100 Parent: Codex.exe ``` Observed event timing: ```text 2026-06-05 21:33:28 PowerShell console started 2026-06-05 21:33:30 OpenConsole.exe prefetch updated 2026-06-05 21:41:22 OpenConsole.exe prefetch updated 2026-06-05 21:41:29 PowerShell.exe prefetch updated ``` After Windows Terminal delegation was removed, the issue persisted as a normal visible console flash, so this is not only a Windows Terminal default-terminal issue. ## Expected behavior Codex Desktop should launch all internal/background command probes without showing any user-visible console window. On Windows, background process inspection should use one of: - `CREATE_NO_WINDOW` - hidden `STARTUPINFO.wShowWindow` - a non-console helper process - direct native process enumeration APIs instead of spawning `powershell.exe` ## Actual behavior Codex Desktop launches short-lived PowerShell commands that visibly flash a black console window. The user sees this even when they did not ask Codex to run a command. ## User impact - Looks like malware or an unknown terminal pop-up. - Breaks user trust in Codex Desktop. - Distracts during normal work. - Makes it hard to tell whether a window came from Codex, Claude Code, MSI Center, Windows Terminal, or another background process. ## Severity Medium. This is not data loss, but it is highly visible, frightening, and makes the application feel unsafe on Windows. ## Suggested fix The Codex Desktop Windows process runner/process monitor should never spawn visible consoles for internal background probes. Please audit the Windows child-process creation path used for process polling and ensure hidden/no-window semantics are applied consistently. Specifically, the code path that runs `powershell.exe -NoProfile -NonInteractive -Command Get-CimInstance Win32_Process ...` should create the child process with no visible console. ## Extra note This is not an MSI Center issue. MSI Center has its own console-host behavior at startup, but this separate repro was captured with Codex-spawned PowerShell process polling. The parent process evidence points to Codex.", "url": "https://github.com/openai/codex/issues/26613", "createdAt": "2026-06-05T13:47:41Z", "updatedAt": "2026-08-13T09:53:50Z", "timestamp": "2026-08-13T09:53:50Z", "metrics": { "reactions": 1, "comments": 12 }, "labels": [ "bug", "windows-os", "app" ], "author": "superPilipala", "state": "open", "assignees": [] }, { "id": "github:openai/codex:issue:26620", "source": "github", "group": "coding-agent-infrastructure", "project": "openai/codex", "kind": "issue", "title": "[Codex App][Windows] Make response file references and artifact cards draggable to external apps", "text": "### What variant of Codex are you using? Codex App / Desktop app ### Platform Windows 11 ### What feature would you like to see? I would like file references and artifact cards shown in Codex responses to be draggable outside the Codex app as real OS file objects. Example: when Codex creates a file and shows a response link/card like: `generated_report.csv (line 1)` I want to be able to drag that link/card directly into another application, such as a browser upload field, Windows Explorer, VS Code, an editor, or another desktop app. ### Current behavior The file reference is visible and clickable inside Codex, but it does not behave like a real draggable file. To use the file elsewhere, I need to open or reveal the containing folder first, then drag the file from Windows Explorer. This interrupts the workflow. ### Desired behavior Codex response file references and file cards should support drag-out behavior: - dragging the file card should provide the actual local file as the drag payload - dragging the blue filename link should also drag the referenced file, not just text - on Windows, this should use normal filesystem drag behavior so other apps receive the file as if it came from Explorer - if the reference includes a line number, the drag should still transfer the file; the line reference can be preserved as text/metadata if supported ### Why this matters Codex often creates CSVs, patches, logs, screenshots, reports, and other artifacts. After Codex produces a file, the natural next step is often to drag it into another app. Making response file references draggable would remove the extra “open folder first” step and make Codex-generated files feel like real local artifacts. Suggested labels: `app`, `enhancement`, `windows-os`. Related issues: - #19785 — draggable workspace file tree/sidebar - #17136 — improve file reference interactions - #17591 — Windows desktop app file links / real filesystem paths", "url": "https://github.com/openai/codex/issues/26620", "createdAt": "2026-06-05T14:41:13Z", "updatedAt": "2026-08-13T03:05:00Z", "timestamp": "2026-08-13T03:05:00Z", "metrics": { "reactions": 0, "comments": 1 }, "labels": [ "enhancement", "windows-os", "app" ], "author": "davidjirovec", "state": "open", "assignees": [] }, { "id": "github:openai/codex:issue:26764", "source": "github", "group": "coding-agent-infrastructure", "project": "openai/codex", "kind": "issue", "title": "Login failed — token exchange failed: error sending request to URL (https://auth.openai.com/oauth/token)", "text": "### What version of the Codex App are you using (From “About Codex” dialog)? 最新版本 ### What subscription do you have? plus ### What platform is your computer? windows ### What issue are you seeing? 错误代码 token_exchange_failed 细节 Token exchange failed: error sending request for url (https://auth.openai.com/oauth/token) ### What steps can reproduce the bug? 无法登入codex，网页版可以正常使用 ### What is the expected behavior? _No response_ ### Additional information _No response_", "url": "https://github.com/openai/codex/issues/26764", "createdAt": "2026-06-06T09:53:30Z", "updatedAt": "2026-08-12T15:44:18Z", "timestamp": "2026-08-12T15:44:18Z", "metrics": { "reactions": 0, "comments": 20 }, "labels": [ "bug", "windows-os", "auth", "app", "connectivity" ], "author": "liuhongwei56", "state": "open", "assignees": [], "change": "updated" }, { "id": "github:openai/codex:issue:26984", "source": "github", "group": "coding-agent-infrastructure", "project": "openai/codex", "kind": "issue", "title": "MCP stdio servers leak pipe fds + orphan child processes → cumulative EMFILE (\"Too many open files\", os error 24)", "text": "# MCP stdio servers leak pipe fds + orphan child processes → cumulative EMFILE (\"Too many open files\", os error 24) ### What version of Codex CLI is running? codex-cli 0.137.0 (also reproduced symptom on long-running 0.12x sessions) ### What subscription do you have? Pro ### Which model were you using? n/a (process/transport bug, model-independent) ### What platform is your computer? Darwin 25.5.0 (macOS 26.5.1) arm64 ### What issue are you seeing? Long-running sessions that use stdio MCP servers slowly accumulate open file descriptors in the **codex parent process** until they hit the per-process soft limit (256 on a default macOS login shell), at which point every subsequent `open()`/`spawn()` fails with `Too many open files (os error 24)`. This is almost certainly the underlying **fd leak** behind the now-closed openai/codex#17806 (\"Repeat `Os { code: 24 }` crashes\"). That issue was closed via [#12216](), which only **hardened the panic** in `AbsolutePathBuf::parent()` so EMFILE no longer crashes the TUI — it did **not** address *why* fds are exhausted. The leak is still present. ## Evidence (live system) A single long-lived TUI session (`codex resume`, soft limit 256) sitting **3 fds under the ceiling**: ``` $ lsof -p | awk 'NR>1{print $5}' | sort | uniq -c | sort -rn 186 PIPE <-- the leak 38 REG (state_*.sqlite WAL/shm, rollout jsonl, logs_*.sqlite) 8 KQUEUE 7 unix 5 IPv4 ... 253 total (soft NOFILE = 256 -> next open() = EMFILE) ``` 186 anonymous PIPE fds for a session with \\~4–5 configured MCP servers (expected ≈3 pipes/server = \\~15). The excess maps almost 1:1 to **orphaned MCP child processes** that the codex parent still holds read pipes to. System-wide, orphaned stdio MCP servers far outnumber the live codex sessions that should own them: ``` $ pgrep -f slack-mcp-server | wc -l # 30 $ pgrep -f xcodebuildmcp | wc -l # 18 $ pgrep -f \"codex app-server\"| wc -l # 9 ``` These are spawned as `npm exec ` / `npx`, i.e. the actual server (`node`) is a **grandchild** under an `npm` wrapper. ## Root-cause analysis (code, codex-rs @ 8f1aad5) Cleanup of stdio MCP servers has three gaps that compound under the MCP **refresh/rebuild** churn. ### 1\\. Teardown is fire-and-forget — never awaits process exit `rmcp-client/src/stdio_server_launcher.rs` `LocalProcessTerminator::terminate` (unix): ```rust let should_escalate = terminate_process_group(pgid) /* killpg SIGTERM */ ...; if should_escalate { spawn(move || { // detached std::thread sleep(PROCESS_GROUP_TERM_GRACE_PERIOD /* 2s */); kill_process_group(pgid); // killpg SIGKILL }); } ``` `RmcpClient::shutdown` (`rmcp-client/src/rmcp_client.rs:678`) calls this and **returns immediately** — the SIGKILL lands ≥2 s later on a detached thread. Nothing awaits actual child exit or pipe EOF. If the runtime/parent is torn down (or the next refresh races) within that window, the SIGKILL thread can be lost, leaving the group alive. ### 2\\. Cancelled-startup path skips explicit terminate entirely On MCP refresh, `core/src/session/mcp.rs::refresh_mcp_servers_inner`: ```rust // :341 cancel old startup token guard.cancel(); // :344 build a brand-new manager — spawns the ENTIRE MCP server set again let (refreshed_manager, cancel_token) = McpConnectionManager::new(...).await; // :377 swap in let mut old_manager = std::mem::replace(&mut *manager, refreshed_manager); // :379 shut down the old one old_manager.shutdown().await; ``` For any old client still mid-handshake, `AsyncManagedClient::shutdown` (`codex-mcp/src/rmcp_client.rs:240`) resolves the shared startup future to `Err(Cancelled)`: ```rust match self.client().await { Ok(client) => client.client.shutdown().await, Err(StartupOutcomeError::Cancelled) => {} // <-- terminate() never called Err(error) => warn!(...), } ``` Cleanup then depends **entirely** on `Drop for StdioServerProcessHandleInner`, which only fires once the last `Arc` clone is dropped — and which itself uses the same fire-and-forget terminate from gap [#1](). The same full-set spawn-then-shutdown churn also runs in the ephemeral connector-discovery manager (`core/src/connectors.rs:273` … `:359`). ### 3\\. Group signalling misses `npm`/`npx` grandchildren Spawn uses bare `command.process_group(0)` (`stdio_server_launcher.rs:263`) and signals `pgid == direct-child PID`. The direct child is the `npm`/`npx` wrapper; the real server is `node`. When the wrapper exits (or the server reparents) the original group no longer covers `node`, so `killpg(SIGTERM/SIGKILL)` misses it → **orphaned node** (the 30/18 above). Note `utils/pty/src/process_group.rs` already has `detach_from_tty`/`setsid`-style helpers, but the stdio MCP launcher does not use a `wait`-and-verify reap. ### Net effect Each refresh/rebuild cycle spawns a fresh server set and tears down the old one **without awaiting death and without reliably reaping the** `npm` **grandchild**. Every orphan keeps its stdout/stderr **write** ends open, so the codex-side **read** pipe + the detached stderr-reader task (`stdio_server_launcher.rs:274`) never reach EOF and never close. Pipe fds in the codex parent grow **monotonically** until EMFILE. ## Suggested fixes 1. **Await actual exit on teardown.** Make `shutdown()`/Drop `waitpid`/`try_wait` the group after SIGTERM→SIGKILL instead of fire-and-forget, so pipes are closed deterministically. 2. **Terminate on the cancelled-startup arm.** In `AsyncManagedClient::shutdown`, call the process terminator on `Err(Cancelled)` rather than relying on `Drop`. 3. **Reap the whole group reliably.** Either spawn the server binary directly (resolve `npm exec`/`npx` to the real entrypoint) or `setsid` + track the session and kill+wait the session, not just the direct child's PID-as-PGID. 4. **(Hardening)** Bound the stderr-reader task to transport lifetime / close the read half on terminate so a lingering grandchild can't pin the pipe. ## Workaround for users Raise the per-process limit before launching (`ulimit -n 65536`, and/or `sudo launchctl limit maxfiles 65536 524288` for GUI-launched servers) and periodically kill orphaned `*-mcp-server` / `npx` processes. This only delays the leak. ### Related * openai/codex#17806 (closed) — same symptom; closed via panic-hardening only, leak not addressed * [#12216]() (closed) — EMFILE panic hardening in `AbsolutePathBuf::parent()` * openai/codex#25243 (open) — distinct root cause (Codex.app re-exec storm vs `syspolicyd`), not MCP", "url": "https://github.com/openai/codex/issues/26984", "createdAt": "2026-06-08T11:10:00Z", "updatedAt": "2026-08-13T12:03:51Z", "timestamp": "2026-08-13T12:03:51Z", "metrics": { "reactions": 4, "comments": 20 }, "labels": [ "bug", "mcp", "CLI" ], "author": "jacobcxdev", "state": "open", "assignees": [] }, { "id": "github:openai/codex:issue:26990", "source": "github", "group": "coding-agent-infrastructure", "project": "openai/codex", "kind": "issue", "title": "Windows Desktop local state is not crash-safe after power loss: pins/projects reset, config regresses, future timestamps", "text": "### What version of the Codex App are you using (From “About Codex” dialog)? Codex Desktop Windows app package: ```text OpenAI.Codex_26.602.4764.0_x64__2p2nqsd0c76g0 Version: 26.602.4764.0 ``` The app was updated before filing this report. Additional local CLI present on the same machine: ```text codex-cli 0.125.0 ``` ### What subscription do you have? ChatGPT Pro ### What platform is your computer? ```text Microsoft Windows 11 Pro Version: 10.0.26200 Build: 26200 Architecture: x64 Filesystem: NTFS ``` ### What issue are you seeing? After power loss / abrupt shutdown, Codex Desktop local state is repeatedly coming back in a partially reset or internally inconsistent state. The user-visible symptoms are: - pinned chats disappear from the sidebar; - saved projects/workspaces disappear or collapse to a single workspace; - some project views show `No chats` even though local conversations still exist; - the TUI/skills refresh can fail because `config.toml` regresses to an invalid `service_tier = \"default\"` value for this installed version; - local metadata can get a far-future timestamp (`7026`), making an old session look newer than real recent sessions. This has happened multiple times after power loss. It looks like the local Desktop/profile state under `%USERPROFILE%\\.codex` is not crash-safe across abrupt shutdowns. The underlying conversations are generally still recoverable from local SQLite/session files, but the UI state and indexes become misleading or broken. ### Concrete local evidence The affected local state directory is `%USERPROFILE%\\.codex`. #### 1. `.codex-global-state.json` was rewritten to a minimal state Before repair, the current `.codex-global-state.json` had effectively collapsed to one workspace: ```text file: %USERPROFILE%\\.codex\\.codex-global-state.pre-repair-20260606-070944.json size: 2,053 bytes pinned-thread-ids: 1 project-order: 1 electron-saved-workspace-roots: 1 thread-workspace-root-hints: 0 active-workspace-roots: [%USERPROFILE%] ``` After reconstructing from a known-good backup and `state_5.sqlite`, the repaired state contained: ```text file: %USERPROFILE%\\.codex\\.codex-global-state.backup-20260606-070944.repaired.json size: 102,112 bytes pinned-thread-ids: 11 project-order: 27 electron-saved-workspace-roots: 27 thread-workspace-root-hints: 675 ``` Current post-repair state, after reopening the app, remains healthy: ```text pinned-thread-ids: 13 project-order: 28 electron-saved-workspace-roots: 27 thread-workspace-root-hints: 675 example project-specific hints: 3 for a project that previously showed `No chats` ``` The repaired JSON is UTF-8 without BOM. The first bytes are: ```text 123,13,10 ``` #### 2. `config.toml` regressed to `service_tier = \"default\"` The broken config contained this at the top: ```toml model = \"gpt-5.5\" model_reasoning_effort = \"xhigh\" personality = \"pragmatic\" sandbox_mode = \"danger-full-access\" approval_policy = \"never\" service_tier = \"default\" ``` The local error was: ```text failed to refresh skills: skills/list failed in TUI: skills/list failed: failed to reload config: C:\\Users\\\\.codex\\config.toml:6:16: unknown variant `default`, expected `fast` or `flex` ``` Restoring a previous fixed backup of `config.toml` removed the parse error. The current restored file no longer contains `service_tier = \"default\"`. #### 3. A local thread and version cache jumped to year 7026 Before repair, one local thread had: ```text id: 911d47ec-a3a4-7503-b8ae-3f47cecabbd4 cwd: updated_utc: 7026-02-04 18:32:49 updated_ms: 159554946769000 rollout_path: %USERPROFILE%\\.codex\\sessions\\7026\\02\\04\\rollout-7026-02-04T15-32-49-911d47ec-a3a4-7503-b8ae-3f47cecabbd4.jsonl ``` `version.json` also had a `last_checked_at` timestamp in 7026: ```json { \"latest_version\": \"0.96.0\", \"last_checked_at\": \"7026-02-04T18:32:48.404538600Z\", \"dismissed_version\": null } ``` The `7026` session file contained only 4 metadata/instruction lines, not meaningful conversation content. After backing up the database and file, I moved it to the matching 2026 path and updated the SQLite row to a 2026 timestamp. Post-repair validation: ```text future files under %USERPROFILE%\\.codex: 0 future threads in state_5.sqlite: 0 ``` #### 4. Local conversation data was still present The state database still contained many threads: ```text state_5.sqlite total threads: 791 active threads: 714 ``` This looks like a local state/index/UI consistency problem rather than complete data deletion. ### What steps can reproduce the bug? This is tied to abrupt shutdown/power loss rather than a deterministic in-app action, but the observed sequence is: 1. Use Codex Desktop on Windows with multiple saved workspaces/projects, pinned chats, and many local conversations. 2. Leave Codex Desktop open with app-server/background processes active. 3. Machine loses power or is abruptly shut down. 4. Restart Windows and open Codex Desktop. 5. Observe that the sidebar has lost pins and saved projects, or project views show `No chats`. 6. In some cases, launch TUI/CLI or trigger skills refresh and observe config parsing failure from `service_tier = \"default\"`. 7. Inspect `%USERPROFILE%\\.codex` and compare: - `.codex-global-state.json` - `state_5.sqlite` - `session_index.jsonl` - `sessions/**/rollout-*.jsonl` - `version.json` The conversations remain mostly recoverable locally, but the UI state and metadata can be corrupted or reset. ### What is the expected behavior? Codex Desktop should make local state persistence crash-safe across abrupt shutdowns. Specifically: - `.codex-global-state.json` should not be replaced by a minimal state after a crash if recoverable state exists. - Writes to local JSON state should be atomic, for example write temp file, fsync, then rename. - `config.toml` should not regress to a value that the installed parser rejects. - Timestamps should be validated or clamped; a local session/version cache should not jump to year 7026. - The app should detect drift between `.codex-global-state.json`, `state_5.sqlite`, `session_index.jsonl`, and existing rollout files. - If project state is incomplete, Codex should expose a supported local repair/reindex command rather than making users inspect and patch SQLite/JSON manually. - Project views should not display `No chats` when matching active local threads exist in `state_5.sqlite` and rollout files exist on disk. ### Actual behavior After power loss, Codex Desktop can reopen with: - pins reduced from 11+ to 1; - saved projects reduced from dozens to 1; - workspace hints removed; - project chat views empty despite active rows in `state_5.sqlite`; - `config.toml` containing `service_tier = \"default\"`, which this install rejects; - local metadata containing future year `7026`. ### Workaround used locally With Codex Desktop closed: 1. Back up the broken files/databases. 2. Restore a known-good `config.toml` without `service_tier = \"default\"`. 3. Rebuild `.codex-global-state.json` from a known-good backup and active rows in `state_5.sqlite`. 4. Preserve and restore: - `pinned-thread-ids` - `project-order` - `electron-saved-workspace-roots` - `active-workspace-roots` - `thread-workspace-root-hints` 5. Write JSON as UTF-8 without BOM. 6. Move the `sessions\\7026\\...` rollout to the equivalent `sessions\\2026\\...` path and update the corresponding SQLite row. 7. Restart Codex Desktop. After that, pins/projects/project hints were visible again. ### Related issues This overlaps with several existing local state/sidebar/path reports, but I did not find an exact duplicate for the power-loss/crash-safety combination: - #17540: Windows app older local threads disappear from sidebar/search while still present on disk. - #24178: conversations become empty and resume fails with `C:\\...` vs `\\\\?\\C:\\...` stale path. - #25500: project sidebar shows `No chats` for projects with older non-archived conversations. - #22452: local thread hidden/stale when `state_5.sqlite` and `session_index.jsonl` drift. - #24425: corrupted session JSON/history after crash; maintainer asked about power loss in discussion. The distinct parts here are: - reproducible trigger is power loss / abrupt shutdown; - `.codex-global-state.json` collapses to a minimal state; - `config.toml` regresses to an invalid `service_tier = \"default\"` for this version; - a local thread and version cache jumped to year `7026`; - the same local profile needed coordinated repair across global state JSON, config TOML, SQLite, session index, and session paths. ### Additional information No raw `logs_2.sqlite`, `auth.json`, full `config.toml`, or rollout content is attached publicly because those files may contain private prompts, local project names, tokens, URLs, or account data. I can provide redacted diagnostics or specific SQL/query output if maintainers say which fields are useful and safe to share.", "url": "https://github.com/openai/codex/issues/26990", "createdAt": "2026-06-08T11:57:05Z", "updatedAt": "2026-08-13T00:59:55Z", "timestamp": "2026-08-13T00:59:55Z", "metrics": { "reactions": 0, "comments": 14 }, "labels": [ "bug", "windows-os", "app", "session", "config" ], "author": "dudantas", "state": "open", "assignees": [] }, { "id": "github:openai/codex:issue:27197", "source": "github", "group": "coding-agent-infrastructure", "project": "openai/codex", "kind": "issue", "title": "Codex App: expose reasoning summaries or progress traces when configured", "text": "### What problem are you trying to solve? In Codex App, turns currently only show a brief blinking `Thinking` state and then the final answer. Even with reasoning-related config enabled, I do not see an expandable reasoning summary, progress trace, or `Thought`-style section while the turn is running or after it completes. This makes it harder to understand what the agent is doing on longer tasks, compare behavior with other agent UIs, or debug cases where the answer is surprising. ### Current behavior - I submit a prompt in Codex App. - The UI shows a blinking `Thinking` label. - The final response appears. - No visible reasoning summary / progress trace is shown. ### Expected behavior It would be helpful if Codex App exposed an optional, expandable reasoning-summary/progress panel when configured, similar in spirit to the way some agent UIs show a `Thought:` or trace section. This does not need to expose private chain-of-thought verbatim; a surfaced reasoning summary or structured progress trace would be enough. Ideally this would work consistently with the existing config knobs: ```toml model_reasoning_summary = \"detailed\" hide_agent_reasoning = false show_raw_agent_reasoning = true ``` If Codex App intentionally does not support showing these events, it would also be helpful for the UI or docs to make that clear. ### Environment - Codex App: 26.602.71036 (bundle version 3685) - Codex CLI: 0.137.0 - macOS: 13.3 (22E252) - Model: gpt-5.5 - Reasoning effort: high - Service tier: fast ### Related context I found a few possibly related issues where reasoning summaries / progress traces appear to be present in some layer but are not reliably visible in a client UI: - #24287 - #16801 - #9470 This request is specifically for Codex App / desktop UI behavior.", "url": "https://github.com/openai/codex/issues/27197", "createdAt": "2026-06-09T14:56:45Z", "updatedAt": "2026-08-12T19:50:41Z", "timestamp": "2026-08-12T19:50:41Z", "metrics": { "reactions": 9, "comments": 2 }, "labels": [ "enhancement", "app", "config" ], "author": "tlerbao", "state": "open", "assignees": [] }, { "id": "github:openai/codex:issue:27207", "source": "github", "group": "coding-agent-infrastructure", "project": "openai/codex", "kind": "issue", "title": "🩹 Restore archived chats access from the main Codex UI", "text": "### Summary Archived chats need to be accessible from the main Codex UI, not hidden under Settings → Archived chats. This appears to be a regression/removal: a user reports this was available from the main UI roughly two weeks ago, and now there is no obvious way to browse all archived chats from the main sidebar. If the user does not remember the chat name/title, search is not enough. ### Current behavior - Archived chats are effectively hidden in **Settings → Archived chats**. - The main sidebar does not provide an obvious **Archived** view/section. - Accidental archive feels like the chat disappeared. - Recovery is not discoverable unless the user already knows the settings location. ### Expected behavior Please restore/add archived chat access to the main UI: - Add an **Archived** section/view in the main sidebar. - Add a command-palette action such as **Show archived chats**. - Make search clearly include archived chats or provide an obvious archived filter/badge. - Show an **Undo archive** toast immediately after archiving. - Keep **Unarchive** available from the thread menu inside the archived-chat list. ### Why this matters Archive is a normal chat-management action, but recovery is currently too hidden. Users who accidentally archive a chat and do not know its title need a direct way to browse archived chats from the primary navigation. Environment: Codex Desktop on macOS.", "url": "https://github.com/openai/codex/issues/27207", "createdAt": "2026-06-09T16:19:22Z", "updatedAt": "2026-08-13T04:22:45Z", "timestamp": "2026-08-13T04:22:45Z", "metrics": { "reactions": 10, "comments": 8 }, "labels": [ "enhancement", "app", "session", "Papercuts 2026", "Papercuts: Source - Truffle Pig", "Papercuts: Type - Confusing" ], "author": "richa65-personal", "state": "open", "assignees": [] }, { "id": "github:openai/codex:issue:27934", "source": "github", "group": "coding-agent-infrastructure", "project": "openai/codex", "kind": "issue", "title": "Allow Linux users to redeem banked Codex rate-limit resets from the web or CLI", "text": "### What variant of Codex are you using? CLI ### What feature would you like to see? Please add a way for Linux users to view and redeem banked Codex rate-limit resets, either from Codex CLI or from a Codex web usage/settings page. ### Additional information Banked resets currently appear to be exposed through the Codex app UI, but the Codex desktop app is not available on Linux. Since Linux users generally rely on Codex CLI, there should be a non-desktop-app way to use this feature. A web implementation would be fine. For example, the reset could be shown and redeemed from a Codex usage/settings page such as: https://chatgpt.com/codex/cloud/settings/analytics A CLI implementation would also work, for example through `/limits`, `/usage`, or a new command. At least as of Codex CLI 0.139.0, there's no option to view or redeem banked resets.", "url": "https://github.com/openai/codex/issues/27934", "createdAt": "2026-06-12T18:48:02Z", "updatedAt": "2026-08-12T17:25:37Z", "timestamp": "2026-08-12T17:25:37Z", "metrics": { "reactions": 1, "comments": 2 }, "labels": [ "enhancement", "rate-limits", "CLI" ], "author": "VictorBenitoGR", "state": "closed", "assignees": [] }, { "id": "github:openai/codex:issue:28084", "source": "github", "group": "coding-agent-infrastructure", "project": "openai/codex", "kind": "issue", "title": "Windows desktop upgrade can leave Browser, Chrome, and Computer Use globally unavailable due to mixed plugin/runtime state", "text": "## Summary After a Codex Windows desktop app update, **Browser**, **Chrome**, and **Computer Use** could all become globally unavailable in Settings. Restarting the app did not repair the state. The failure was caused by several pieces of old and new state being mixed across the bundled marketplace snapshot, version cache, Chrome native host, and `cua_node` runtime. This should be handled atomically by the desktop app updater. A periodic self-heal process is not an appropriate solution because it adds more mutable state and can conceal upgrade defects. ## Environment - Windows desktop app package: `OpenAI.Codex_26.609.4994.0_x64` - Bundled Browser/Chrome/Computer Use plugin version: `26.609.41114` - `cua_node` runtime archive: `cua-node-0.0.1-20260609000952-8714bea94049-win32-x64.zip` - `@oai/sky`: `0.4.10` - Codex Doctor: `0.140.0-alpha.2` User-specific names and paths have been removed from this report. ## Observed failures 1. The reconstructed bundled marketplace snapshot under `.codex/.tmp/bundled-marketplaces/openai-bundled` was incomplete/stale and at one point contained only the Chrome plugin without a valid marketplace index. 2. `plugins/cache/openai-bundled/chrome/latest` pointed to the temporary marketplace source instead of the immutable versioned cache directory. 3. A stale `extension-host.exe` from the previous version retained a lock on `plugins/chrome/extension-host/windows/x64`, causing repeated marketplace reconciliation failures (`EBUSY`). 4. The Windows sandbox failed to start the runtime with `CreateProcessAsUserW failed: 5` until the runtime path had read/execute traversal permissions for `CodexSandboxUsers`. 5. The bundled Computer Use plugin imports: ```js @oai/sky/dist/project/cua/sky_js/src/targets/windows/internal/computer_use_client_base.js ``` The file exists in the bundled `@oai/sky` package, but `@oai/sky@0.4.10` only exports: ```json { \".\": \"./dist/project/cua/sky_js/src/index.js\" } ``` This produces: ```text ERR_PACKAGE_PATH_NOT_EXPORTED: Package subpath './dist/project/cua/sky_js/src/targets/windows/internal/computer_use_client_base.js' is not defined by \"exports\" ``` The app package copy and the extracted local runtime copy of `@oai/sky/package.json` had identical SHA-256 hashes, so this was a bundled plugin/runtime compatibility mismatch rather than stale local runtime content. ## Expected upgrade behavior The updater should treat the bundled marketplace, plugin cache, runtime, native host configuration, and active version pointers as one versioned transaction: 1. Stop or retire previous-version native host processes before replacing/reconciling their files. 2. Stage the complete bundled marketplace and verify its index/manifests before switching the active pointer. 3. Keep `latest` links pointed only at immutable versioned cache directories, never at a temporary reconciliation source. 4. Validate plugin imports against the exact bundled runtime package exports before release. 5. Apply required sandbox read/execute/traversal ACLs when extracting a new runtime. 6. Switch active state only after all checks pass; retain the previous complete version for rollback. 7. Remove or ignore incompatible old cache entries rather than merging them into the new version. ## Validation after manual repair After rebuilding the marketplace from the installed AppX resources, repointing Chrome `latest` to the versioned cache, reinstalling the native host manifest, applying minimal runtime traversal permissions, and adding the missing exact package export: - `browser`, `chrome`, and `computer-use` all reported `installed, enabled`. - Computer Use successfully performed a real `list_apps` call and returned 40 applications, including Google Chrome. - `codex doctor --summary` reported `16 ok`, `0 fail`. Please fix this in the desktop update/install migration path rather than adding a periodic repair task.", "url": "https://github.com/openai/codex/issues/28084", "createdAt": "2026-06-13T14:53:59Z", "updatedAt": "2026-08-13T15:25:10Z", "timestamp": "2026-08-13T15:25:10Z", "metrics": { "reactions": 1, "comments": 5 }, "labels": [ "bug", "windows-os", "sandbox", "app", "skills", "computer-use", "browser" ], "author": "Vagex", "state": "open", "assignees": [] }, { "id": "github:openai/codex:issue:28087", "source": "github", "group": "coding-agent-infrastructure", "project": "openai/codex", "kind": "issue", "title": "Codex Desktop can get stuck on sqlite state backfill with partial new index while legacy state is complete", "text": "### What version of the Codex App are you using? Codex Desktop `26.609.41114` on macOS. The app-server version reported after recovery was: ```text currentVersion=0.140.0-alpha.2 ``` ### What subscription do you have? ChatGPT Pro. ### What platform is your computer? macOS 15.6.1 (`darwin`), Apple Silicon. ### What issue are you seeing? Codex Desktop can get stuck during startup when the new SQLite state DB is left in a partial backfill state. The user-facing symptom was that the app stayed around \"Rebuilding conversation history\" / failed to initialize, and the app-server repeatedly failed the initialization handshake. This looked similar to a local-history loss incident, but the original session files and the legacy/root state DB were still present. The relevant Desktop log repeatedly showed: ```text failed to initialize sqlite state runtime under ~/.codex/sqlite: timed out waiting for state db backfill at ~/.codex after 30s (status: running) initialize_handshake_result outcome=failure ``` This repeated for several startup attempts. After the local state was repaired from a known-good state backup, the next Desktop startup logged: ```text Current reported app-server version: currentVersion=0.140.0-alpha.2 initialize_handshake_result durationMs=163 outcome=success transportKind=stdio ``` ### Local state evidence Before repair, the new state DB at `~/.codex/sqlite/state_5.sqlite` was internally readable and passed SQLite integrity check, but appeared to be a half-built index: ```text integrity=ok backfill_state.status=running threads=394 sum(has_user_event)=0 archived=206 thread_dynamic_tools=0 ``` At the same time, the legacy/root state DB at `~/.codex/state_5.sqlite` still had complete thread metadata: ```text integrity=ok backfill_state.status=complete threads=410 sum(has_user_event)=306 archived=206 thread_dynamic_tools=869 ``` After restoring the complete state index, the current state DB looked healthy again: ```text integrity=ok backfill_state.status=complete threads=410+ sum(has_user_event)=306 thread_dynamic_tools=869 ``` ### Expected behavior Codex Desktop should detect and recover from this stale or failed backfill state instead of repeatedly failing startup after 30 seconds. Possible safe behaviors: - detect `backfill_state.status=running` from a previous failed app-server process and resume or reset the backfill lease safely; - detect that the new sqlite index has `threads > 0` but `sum(has_user_event)=0` / `thread_dynamic_tools=0` while the legacy/root DB has complete metadata; - fall back to a safe rebuild path, or show a clear local-state recovery prompt that does not risk wiping thread metadata; - avoid presenting a partial new sqlite index as valid sidebar/project history. ### Actual behavior The app-server repeatedly failed initialization with: ```text timed out waiting for state db backfill at ~/.codex after 30s (status: running) ``` This made the Desktop app unusable until the local state index was repaired manually from backup. ### Related issues This seems related to, but more specific than: - #23787, which reports a Windows startup crash involving SQLx checksum drift and backfill timeout. - #23979, which reports local project conversation history missing after update while threads still exist. The distinguishing detail here is that on macOS the new sqlite state DB passed `integrity_check` but was stuck with `backfill_state.status=running` and had an obviously incomplete thread index, while the legacy/root state DB was still complete.", "url": "https://github.com/openai/codex/issues/28087", "createdAt": "2026-06-13T14:58:00Z", "updatedAt": "2026-08-13T00:13:47Z", "timestamp": "2026-08-13T00:13:47Z", "metrics": { "reactions": 2, "comments": 2 }, "labels": [ "bug", "app", "app-server" ], "author": "wsy150728", "state": "open", "assignees": [] }, { "id": "github:openai/codex:issue:28404", "source": "github", "group": "coding-agent-infrastructure", "project": "openai/codex", "kind": "issue", "title": "Codex Desktop rewrites user notify hook through SkyComputerUseClient --previous-notify", "text": "## Environment - macOS: 26.5, build 25F71 - Codex Desktop: 26.609.71144, build 3952 - Codex CLI: 0.137.0 - Computer Use helper: 1.0, build 809 - Platform: macOS Apple Silicon ## Summary Codex Desktop rewrites a user-owned `notify` command into a Computer Use wrapper on app restart. The rewritten command launches `SkyComputerUseClient turn-ended` first and stores the original notifier under `--previous-notify`. This causes macOS Gatekeeper/codesign failures for `Codex Computer Use.app` even though the user only configured a normal notification script. This appears to be a Desktop startup/plugin migration behavior, not the standalone CLI. ## Original user config Before restarting Codex Desktop, `~/.codex/config.toml` contained: ```toml notify = [\"uv\",\"run\",\"--quiet\",\"/Users/banteg/.codex/notify_telegram.py\"] [plugins.\"computer-use@openai-bundled\"] enabled = true ``` ## Actual behavior After restarting Codex Desktop, the config was rewritten to: ```toml notify = [\"/Users/banteg/.codex/computer-use/Codex Computer Use.app/Contents/SharedSupport/SkyComputerUseClient.app/Contents/MacOS/SkyComputerUseClient\", \"turn-ended\", \"--previous-notify\", \"[\\\"uv\\\",\\\"run\\\",\\\"--quiet\\\",\\\"\\\\/Users\\\\/banteg\\\\/.codex\\\\/notify_telegram.py\\\"]\"] ``` After this rewrite, macOS frequently shows: ```text \"Codex Computer Use.app\" is damaged and can't be opened. You should move it to the Trash. This file was downloaded on an unknown date. ``` The dialog appears around Codex startup / turn completion, even when Computer Use was not explicitly requested. The original notification script is now only invoked through the Computer Use helper. ## Expected behavior Codex Desktop should not overwrite a user-owned `notify` command with a Computer Use wrapper on restart. If Desktop needs a turn-ended Computer Use hook, it should use a separate internal hook mechanism rather than mutating `notify`, or it should at least preserve explicit user configuration and provide an opt-out. In particular: - `notify = [\"uv\", ...]` should remain unchanged across Desktop restarts and updates. - Enabling Computer Use should not make every turn-ended notification depend on launching `SkyComputerUseClient`. - A Computer Use helper launch/signing failure should not break unrelated user notification hooks. ## Additional evidence The helper binary appears to be the same across the local runtime, plugin cache, and app bundle by SHA-256: ```text 7727bcf3b3d648a7d28f67f394a1a114e472e63d7f1d497194945f8bede3fb58 ``` Paths checked: ```text /Users/banteg/.codex/computer-use/Codex Computer Use.app/Contents/MacOS/SkyComputerUseService /Users/banteg/.codex/plugins/cache/openai-bundled/computer-use/1.0.809/Codex Computer Use.app/Contents/MacOS/SkyComputerUseService /Applications/Codex.app/Contents/Resources/plugins/openai-bundled/plugins/computer-use/Codex Computer Use.app/Contents/MacOS/SkyComputerUseService ``` This suggests the immediate problem is not a user-created bad notifier command. The Desktop app is actively migrating/wrapping `notify` through Computer Use on startup. ## Workaround Manually restoring the direct notifier stops the immediate issue until Codex Desktop is restarted again: ```toml notify = [\"uv\",\"run\",\"--quiet\",\"/Users/banteg/.codex/notify_telegram.py\"] ``` But restarting Codex Desktop rewrites it again when Computer Use is enabled, so the workaround is not stable for users who need Computer Use.", "url": "https://github.com/openai/codex/issues/28404", "createdAt": "2026-06-15T22:51:41Z", "updatedAt": "2026-08-12T13:58:21Z", "timestamp": "2026-08-12T13:58:21Z", "metrics": { "reactions": 1, "comments": 5 }, "labels": [ "bug", "app", "hooks", "config", "computer-use" ], "author": "banteg", "state": "open", "assignees": [], "change": "updated" }, { "id": "github:openai/codex:issue:28507", "source": "github", "group": "coding-agent-infrastructure", "project": "openai/codex", "kind": "issue", "title": "Selected model is at capacity. Please try a different model.", "text": "### What version of the Codex App are you using (From “About Codex” dialog)? 26.609.71450 ### What subscription do you have? Pro 5x ### What platform is your computer? Microsoft Windows NT 10.0.26200.0 x64 ### What issue are you seeing? I am writing to report a persistent issue with the Codex GPT-5.5 model. Over the past hour, I have received the error message 'Selected model is at capacity. Please try a different model' multiple times. These interruptions have been frequent enough to prevent me from completing even a short development sprint. Given that I have been using the service for less than an hour, the current rate of service disruption is making it impossible to maintain a productive workflow. Please investigate whether there are capacity constraints affecting my account or the model endpoint specifically. ### What steps can reproduce the bug? Uploaded performance trace: 019ea6e8-ebaa-7c73-b0a1-29e8f682b8bb ### What is the expected behavior? _No response_ ### Additional information _No response_", "url": "https://github.com/openai/codex/issues/28507", "timestamp": "2026-08-12T13:15:47Z", "metrics": { "reactions": 33, "comments": 33 }, "labels": [ "bug", "rate-limits", "app" ], "author": "zhangwenzheng0451", "assignees": [], "change": "new" }, { "id": "github:openai/codex:issue:28667", "source": "github", "group": "coding-agent-infrastructure", "project": "openai/codex", "kind": "issue", "title": "Windows CLI /app fails to open Desktop thread with Start-Process Access denied", "text": "### What version of Codex CLI is running? `codex-cli 0.140.0` Installed with the standalone Windows installer. > **Update (2026-08-13):** Current `main` still has two different Windows Desktop launch paths: `codex app` opens the registered `codex://` protocol, while TUI `/app` directly starts the packaged executable. The current-source comparison and validation are recorded in [this follow-up](https://github.com/openai/codex/issues/28667#issuecomment-5271080647). The original 0.140.0 reproduction below remains unchanged. ### What subscription do you have? ChatGPT Pro. ### Which model were you using? gpt-5.5. ### What platform is your computer? Output requested by the issue template: ```text Microsoft Windows NT 10.0.19045.0 x64 ``` Windows edition: Windows 10 Pro 22H2. ### What terminal emulator and version are you using (if applicable)? Windows Terminal 1.24.11321.0 Shell: Windows PowerShell 5.1.19041.6456 (Desktop edition) ### Codex doctor report Summary of `codex doctor --json` with unnecessary path and session details omitted: ```json { \"schemaVersion\": 1, \"codexVersion\": \"0.140.0\", \"overallStatus\": \"warning\", \"checks\": { \"installation\": \"ok\", \"runtime.provenance\": \"ok; standalone on windows-x86_64\", \"config.load\": \"ok\", \"auth.credentials\": \"ok\", \"state.paths\": \"ok\", \"network.provider_reachability\": \"ok\", \"network.websocket_reachability\": \"ok\", \"mcp.config\": \"ok\", \"terminal.env\": \"ok\" }, \"notableWarning\": \"state.rollout_db_parity: rollout files and state DB thread inventory differ\", \"failedChecks\": 0 } ``` The warning is about older rollout/session inventory parity and does not appear related to launching Codex Desktop from `/app`. ### What issue are you seeing? On Windows, the Codex CLI `/app` command fails to open the current CLI thread in Codex Desktop. The failure happens even though Codex Desktop is installed and registered. Observed error with Codex CLI 0.140.0: ```text Failed to open this session in Codex Desktop: Start-Process : This command cannot be run due to the error: Access is denied. At line:23 char:1 + Start-Process -FilePath $exe -WorkingDirectory $appDir -ArgumentList ... + ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ + CategoryInfo : InvalidOperation: (:) [Start-Process], InvalidOperationException + FullyQualifiedErrorId : InvalidOperationException,Microsoft.PowerShell.Commands.StartProcessCommand. Install or launch Codex Desktop and try again. ``` Codex Desktop registration on the same machine: ```text Codex Desktop package: OpenAI.Codex_26.611.8273.0_x64__2p2nqsd0c76g0 Codex Desktop AppID: OpenAI.Codex_2p2nqsd0c76g0!App ``` The same failure was reproduced after confirming the Desktop package version above. `Get-StartApps -Name 'Codex'` returns the AppID above, so this does not appear to be a missing Desktop install. I traced the failure to the Windows `/app` launcher path. It builds a PowerShell script that locates the AppX/MSIX install location and starts the packaged executable directly: ```powershell $installLocation = (Get-AppxPackage -Name OpenAI.Codex -ErrorAction SilentlyContinue).InstallLocation $appDir = Join-Path $installLocation 'app' $exe = Join-Path $appDir 'Codex.exe' $app = Join-Path $appDir 'resources\\app.asar' Start-Process -FilePath $exe -WorkingDirectory $appDir -ArgumentList @('resources\\app.asar', $url) ``` Starting the packaged `Codex.exe` directly from `C:\\Program Files\\WindowsApps\\...` appears to be what triggers the Windows `Access is denied` error. The same thread opens successfully in Codex Desktop when launched through the registered protocol handler: ```powershell Start-Process 'codex://threads/' ``` This confirms that Codex Desktop is installed, registered, and able to load the thread. Related but not identical issues: - #28031 reports direct execution of a bundled WindowsApps `codex.exe` failing with access denied. - #28393 reports a generated `apply_patch` wrapper pointing at a WindowsApps `codex.exe`. This issue is specifically about the CLI TUI `/app` handoff to Codex Desktop. ### What steps can reproduce the bug? 1. Install Codex Desktop on Windows. 2. Install Codex CLI 0.140.0 with the standalone Windows installer. 3. Start or resume a Codex CLI thread. 4. Run `/app` from the CLI TUI. 5. Observe `Failed to open this session in Codex Desktop` with `Start-Process ... Access is denied`. ### What is the expected behavior? `/app` should open the current CLI thread in Codex Desktop. On Windows, the TUI `/app` command should use the registered `codex://threads/` protocol handler instead of directly executing the AppX/MSIX package's `Codex.exe` from `C:\\Program Files\\WindowsApps`. The CLI `codex app` command already opens a `codex://threads/new?...` URL through PowerShell `Start-Process -FilePath $target`, which avoids direct execution of the WindowsApps packaged executable. ### Additional information I prepared and tested a small candidate patch in a fork branch: https://github.com/starriet9/codex/tree/fix/windows-app-open-thread-protocol Summary of the candidate change: - Verify the stable AppX/MSIX package identity (`OpenAI.Codex` with publisher ID `2p2nqsd0c76g0`) without depending on the Start-menu display name (`Codex` versus `ChatGPT`). - Open the existing `codex://threads/` URL with `Start-Process -FilePath $url`. - Avoid constructing or directly launching `Codex.exe`, `ChatGPT.exe`, or `resources\\app.asar` from the protected WindowsApps package. - Add a regression test that verifies the package-identity check and registered-protocol launch while rejecting the direct-executable path. Local verification on Windows: ```powershell cargo fmt --check cargo test -p codex-tui windows_desktop_app_launch_uses_protocol_handler --lib ``` Both passed. I also cherry-picked the patch onto the 0.140.0 tag and tested it manually from the TUI. With the patch applied, `/app` successfully opened the current thread in Codex Desktop. I am not opening a PR yet because `docs/contributing.md` says external PRs are by invitation only. If this approach matches the intended Desktop handoff behavior, I can open a focused PR from the branch above.", "url": "https://github.com/openai/codex/issues/28667", "createdAt": "2026-06-17T05:26:21Z", "updatedAt": "2026-08-13T07:10:11Z", "timestamp": "2026-08-13T07:10:11Z", "metrics": { "reactions": 1, "comments": 7 }, "labels": [ "bug", "windows-os", "TUI", "CLI" ], "author": "starriet9", "state": "open", "assignees": [] }, { "id": "github:openai/codex:issue:28726", "source": "github", "group": "coding-agent-infrastructure", "project": "openai/codex", "kind": "issue", "title": "Codex IDE extension freezes code-server sidebar on desktop Chromium browsers", "text": "## Summary Codex IDE extension freezes code-server when opening the Codex sidebar on desktop Chromium-based browsers. The same code-server instance works normally without the Codex extension, and Android Samsung Internet can use the Codex sidebar much more reliably. ## Environment - Server OS: Arch Linux - Server surface: code-server - code-server version: 4.123.0, VS Code base 1.123.0 - Codex IDE extension version tested in code-server: `openai.chatgpt-26.602.71036-linux-x64` - Affected clients: - Arch Linux Chromium / Chrome / Edge-family Chromium browser - Windows Edge / Chrome-family Chromium browser - Less affected / working client: - Android Samsung Internet connecting to the same code-server instance ## Symptoms - With the Codex extension installed, opening the Codex sidebar freezes the code-server browser UI. - The freeze happens before opening a specific thread, during sidebar / Codex home / thread list visualization. - The UI appears usable for a few seconds, then freezes after the sidebar is opened. - Removing the Codex extension makes code-server work normally. - Using a mobile Android user agent in desktop Chromium did not avoid the freeze. ## Timeline - The issue started suddenly within the last week. - Arch Linux and code-server were updated after the first freeze, but the freeze persisted. - This makes the code-server update less likely to be the original trigger. ## Reproduction Steps 1. Run code-server on Arch Linux. 2. Connect from a desktop Chromium-based browser. 3. Install / enable the Codex IDE extension. 4. Open the Codex sidebar. 5. Observe the browser / code-server UI freezing during sidebar initialization. ## Diagnostics Performed - Removed Codex extension: freeze disappeared. - Tested desktop Chromium with mobile-sized window, disabled browser extensions, and Android Samsung Internet user agent: freeze still reproduced. - Tested Android Samsung Internet against the same code-server server: Codex sidebar worked much more reliably. - Isolated Codex home for code-server: - Used separate `CODEX_HOME=/home/smoke_nb_sv/.codex-code-server`. - Copied only auth/config/installation id. - Large session files and old session index were excluded. - Quarantined large session files: - Original `~/.codex/sessions` had about 211 MB total, largest file about 133 MB. - Moving large and old session files out did not fix the freeze. - Disabled plugin-related features for code-server's Codex app-server: - Launched app-server through a wrapper with: - `--disable plugins` - `--disable remote_plugin` - `--disable plugin_sharing` - Freeze still reproduced. - Disabled Codex Chat Session Item Provider registration in the extension bundle as a diagnostic patch. - Freeze still reproduced. - Dropped noisy IPC broadcasts in the extension bundle as a diagnostic patch: - `thread-stream-state-changed` - `thread-read-state-changed` - `thread-queued-followups-changed` - `query-cache-invalidate` - This reduced the earlier broadcast warning flood, but the freeze remained. - Disabled/replaced the recent thread list calculation in the webview bundle with an empty list as a diagnostic patch. - Freeze still reproduced. ## Logs / Observations Earlier logs repeatedly showed: ```text [IpcClient] Received broadcast but no handler is configured method=thread-stream-state-changed Ignoring ipc-broadcast expectedVersion=6 method=thread-stream-state-changed ... version=7 ``` After broadcast-drop diagnostics, that warning flood was reduced, but the freeze persisted. Later `remoteexthost.log` showed workspace storage lock conflicts and multiple extension hosts: ```text EEXIST: file already exists, open '/home/.../.local/share/code-server/User/workspaceStorage/.../vscode.lock' Lock ... Could not acquire lock, checking if the file is stale. Lock ... The lock does not look stale, giving up. ``` During repeated reload/freeze tests, multiple code-server extensionHost processes and multiple Codex app-server processes accumulated. Several stale `workspaceStorage/*/vscode.lock` files pointed to dead extensionHost PIDs and had to be removed manually. ## Current Hypothesis This looks like a new compatibility issue in the combination of: - code-server - desktop Chromium-based browsers - Codex IDE extension webview/sidebar initialization - Codex app-server / IPC / VS Code ChatSession initialization - possibly workspaceStorage lock / repeated extensionHost startup behavior It does not appear to be only a large local session-history issue, because isolating `CODEX_HOME` and removing large sessions did not fix it. It does not appear to be only plugin/remote-plugin sync, because disabling those app-server features did not fix it. It does not appear to be only the recent thread list data, because forcing the recent thread list calculation to return an empty list did not fix it. The Android Samsung Internet result is notable: the same code-server UI and server worked much better there, while desktop Chromium browsers on Linux/Windows froze. ## Request Please investigate Codex IDE extension compatibility with code-server, especially: - Sidebar/webview initialization on desktop Chromium clients - ChatSession provider activation in VS Code-compatible web environments - Codex app-server IPC broadcast handling in code-server - Behavior when multiple extensionHost processes / workspaceStorage locks are created after reloads/freezes - Whether `thread-stream-state-changed` and related events can cause main-thread blocking or repeated webview work in code-server ## Notes The local extension bundle was modified for diagnostics only, with backups retained. The issue reproduced before those patches were applied.", "url": "https://github.com/openai/codex/issues/28726", "createdAt": "2026-06-17T13:05:10Z", "updatedAt": "2026-08-13T13:39:34Z", "timestamp": "2026-08-13T13:39:34Z", "metrics": { "reactions": 5, "comments": 22 }, "labels": [ "bug", "extension", "app-server", "performance" ], "author": "SMOKE-19", "state": "open", "assignees": [] }, { "id": "github:openai/codex:issue:28864", "source": "github", "group": "coding-agent-infrastructure", "project": "openai/codex", "kind": "issue", "title": "Add shortcuts to edit or remove specific queued follow-up inputs in the TUI", "text": "### What variant of Codex are you using? CLI ### What feature would you like to see? When Codex is working, users can queue follow-up inputs before the current turn finishes. This is useful, but the queue is currently hard to manage once more than one follow-up has been added. The main issue is that queued messages are visible, but they are not directly actionable by position. If I queue several follow-ups and then notice that the second one is wrong, outdated, duplicated, or no longer relevant, I need a faster way to fix that exact item without interrupting the current turn or reshuffling the queue manually. This matters during long-running agent sessions because users often think ahead while Codex is still running. The queue becomes a lightweight plan for the next few interactions, so mistakes in the queue can easily send the agent down the wrong path. ## Feature Request Add numbered controls for queued follow-up inputs: * Display queued follow-ups with stable numbers. * Use `Option/Alt + number` to edit a specific queued message. * Use `Option/Alt + Shift + number` to remove a specific queued message. * Preserve the original queue position when an edited message is submitted back into the queue. * Keep the existing “edit latest queued message” shortcut as a fallback. * Pause queue running while editing queue. For example: * `Option + 2` restores the second queued follow-up into the composer for editing. * `Option + Shift + 2` removes the second queued follow-up from the queue. * `Option + 0` can target the tenth queued item if supported. ## Why This Should Be Implemented Queued follow-ups are already a strong workflow feature, but without direct queue management they become fragile once the queue contains multiple items. Users need to be able to correct the queue without stopping the current agent turn. This would improve the TUI in a few concrete ways: * Reduces accidental submissions of stale or incorrect follow-ups. * Makes queued input safer to use during long-running tasks. * Lets users manage future instructions without interrupting the agent. * Matches the visible UI model: if queued items are shown as a list, numbered shortcuts make them directly addressable. * Keeps the interaction keyboard-native and fast, which fits the terminal UI. * Avoids adding modal UI or mouse-dependent behavior. This is especially useful for users who actively steer Codex during long tasks, where queued follow-ups may include corrections, next steps, or additional constraints. Being able to edit or remove a specific queued item makes the queue feel intentional rather than append-only. ## Existing Implementation I implemented this functionality in my own Codex fork and have been using it successfully during long-running agent sessions. Implementation: [Commit 31bf78a0ba3c17651f812fae03461b98de3c77df](https://github.com/0xBRM/codex/commit/31bf78a0ba3c17651f812fae03461b98de3c77df?utm_source=chatgpt.com) Let me open the PR @tibo-openai :] ### Additional information _No response_", "url": "https://github.com/openai/codex/issues/28864", "createdAt": "2026-06-18T06:08:19Z", "updatedAt": "2026-08-13T17:33:30Z", "timestamp": "2026-08-13T17:33:30Z", "metrics": { "reactions": 12, "comments": 6 }, "labels": [ "enhancement", "TUI", "CLI" ], "author": "0xBRM", "state": "open", "assignees": [] }, { "id": "github:openai/codex:issue:28919", "source": "github", "group": "coding-agent-infrastructure", "project": "openai/codex", "kind": "issue", "title": "Windows Codex app missing “\\control other devices\"” tab in Settings > Connections", "text": "### What version of the Codex App are you using (From “About Codex” dialog)? Version 26.611.62324 • Released Jun 17, 2026 ### What subscription do you have? Pro ### What platform is your computer? `Microsoft Windows NT 10.0.26200.0 x64` ### What issue are you seeing? I want to control codex remotely from my windows pc, under the connections tab the \"control other devices\" tab is missing. Displayed are \"control this pc\" and \"ssh\" ### What steps can reproduce the bug? Opening the connection settings ### What is the expected behavior? control other devices tab being displayed and I can control ### Additional information \"Image\"", "url": "https://github.com/openai/codex/issues/28919", "createdAt": "2026-06-18T14:02:04Z", "updatedAt": "2026-08-13T07:43:38Z", "timestamp": "2026-08-13T07:43:38Z", "metrics": { "reactions": 33, "comments": 31 }, "labels": [ "bug", "windows-os", "app", "remote" ], "author": "zi070410", "state": "open", "assignees": [] }, { "id": "github:openai/codex:issue:28969", "source": "github", "group": "coding-agent-infrastructure", "project": "openai/codex", "kind": "issue", "title": "Add setting to disable the auto-resolve in 60 seconds for questions", "text": "### What version of Codex CLI is running? codex-cli 0.141.0 ### What subscription do you have? Plus ### Which model were you using? gpt-5.5 ### What platform is your computer? Linux 7.0.3-arch1-2 #1 SMP PREEMPT_DYNAMIC Fri, 01 May 2026 15:49:22 +0000 x86_64 GNU/Linux ### What terminal emulator and version are you using (if applicable)? Alacritty ### Codex doctor report ```json not available ``` ### What issue are you seeing? Codex will automatically accept the recommended answer to a question within 60 seconds. ### What steps can reproduce the bug? 1. Go to plan mode 2. Write a plan prompt that will make Gpt to ask you a question 3. Notice you have a 60 second delay to answer the question ### What is the expected behavior? There should be a setting to disable the 60-second auto-resolving. ### Additional information _No response_", "url": "https://github.com/openai/codex/issues/28969", "createdAt": "2026-06-18T19:54:02Z", "updatedAt": "2026-08-13T11:33:08Z", "timestamp": "2026-08-13T11:33:08Z", "metrics": { "reactions": 198, "comments": 72 }, "labels": [ "bug", "CLI", "config", "plan" ], "author": "antoyo", "state": "open", "assignees": [] }, { "id": "github:openai/codex:issue:29235", "source": "github", "group": "coding-agent-infrastructure", "project": "openai/codex", "kind": "issue", "title": "Codex asks for permission despite full access and approval prompts disabled", "text": "## Summary Codex repeatedly asks the user for permission before ordinary actions even when the thread is configured with full filesystem access and approval prompts disabled. ## User impact This breaks flow across threads. The user expects Codex to proceed with normal local reads, edits, commands, and safe local commands, but the assistant keeps interrupting to ask for permission. ## Observed behavior - In multiple Codex threads, the assistant asks for permission before continuing. - This happens even when the session has unrestricted filesystem access. - This happens even when approval prompts should not be requested. - In the current thread, the assistant had to be corrected with: \"you have full acces why do you keep asking for permission\" and then clarified that this is happening \"in all my threads\". ## Expected behavior When a thread has full access and approval prompts disabled, Codex should proceed without asking for permission for ordinary, non-destructive local work. Codex should still ask for explicit confirmation for actions with major external or destructive consequences, such as: - deleting user data - force-resetting git history - sending email - publishing changes - modifying calendars or external accounts - making irreversible changes outside the requested scope ## Environment evidence from current thread - Surface: Codex desktop app, projectless local thread - Date observed: 2026-06-20 - Filesystem access: unrestricted / full access - Approval behavior expected: no approval prompts for shell commands - Active permission profile presented to the assistant included unrestricted filesystem access and instructions not to request escalation. ## Likely cause The assistant appears to be over-applying a permission-request behavior despite the active thread configuration. This may be one of: - model behavior not honoring the current approval policy - stale permission assumptions carried across threads - UI/tooling exposing full access while the assistant still believes approval is required - conflicting instruction handling around tool safety ## Reproduction steps 1. Open a Codex thread configured with full filesystem access. 2. Ensure approval prompts are disabled / not required. 3. Ask Codex to perform ordinary local work, such as reading files, editing a file, running a safe command, or installing a local dependency. 4. Observe that Codex asks for permission anyway. ## Requested fix Codex should align its behavior with the active permission profile: - If approval prompts are disabled, do not ask for approval for ordinary local operations. - Only ask for confirmation when the action itself is destructive, externally visible, or irreversible. - Make the assistant aware that `approval_policy=never` means it should not request escalation or permission prompts.", "url": "https://github.com/openai/codex/issues/29235", "createdAt": "2026-06-20T15:46:16Z", "updatedAt": "2026-08-13T04:29:25Z", "timestamp": "2026-08-13T04:29:25Z", "metrics": { "reactions": 17, "comments": 3 }, "labels": [ "bug", "model-behavior", "sandbox", "app" ], "author": "mrlightsource-create", "state": "open", "assignees": [] }, { "id": "github:openai/codex:issue:29316", "source": "github", "group": "coding-agent-infrastructure", "project": "openai/codex", "kind": "issue", "title": "Codex App file manager: support drag-and-drop import and right-click delete", "text": "## Feedback Please improve file management in the Codex desktop app file tree. Two small actions would make the workspace file manager much more practical: 1. Allow users to drag files or folders into the Codex file tree / workspace so they can quickly add assets, documents, screenshots, or project files without switching to VS Code or a system file manager. 2. Add a `Delete` action to the file/folder right-click context menu in the Codex file tree. ## Current behavior In the Codex desktop app file tree, right-clicking a file currently shows options such as: - Open in VS Code - Open with - Copy path - Add to chat There is no obvious way to delete a file from this menu. To delete files, users have to switch to VS Code, use the terminal, or ask Codex to run a command. Likewise, adding local files into the workspace is less direct than a normal file manager because drag-and-drop import is not available. ## Desired behavior - Drag a local file/folder into the Codex workspace file tree to copy or move it into the current directory. - Right-click a file/folder and choose `Delete`. - Show a confirmation prompt before deleting, especially for folders. - Refresh the file tree automatically after the operation. - Ideally support undo/move-to-trash where the OS provides it; otherwise make the confirmation clear. ## Why this matters Codex is increasingly useful as a primary coding/workspace surface. Basic file-management actions should be available without leaving the app. Drag-and-drop import and right-click delete would reduce context switching and make common workflows, such as adding images/assets and cleaning generated files, much smoother. ## Related issues Related but not identical: - #19785 asks for a draggable workspace file tree/sidebar. - #3761 asks for drag-and-drop non-image files in the VS Code extension.", "url": "https://github.com/openai/codex/issues/29316", "createdAt": "2026-06-21T08:17:53Z", "updatedAt": "2026-08-13T03:04:13Z", "timestamp": "2026-08-13T03:04:13Z", "metrics": { "reactions": 1, "comments": 1 }, "labels": [ "enhancement", "app" ], "author": "maxboss10086", "state": "open", "assignees": [] }, { "id": "github:openai/codex:issue:29343", "source": "github", "group": "coding-agent-infrastructure", "project": "openai/codex", "kind": "issue", "title": "Chrome plugin, browser and computer use refuse to interact with certain sites.", "text": "### What version of the Codex App are you using (From “About Codex” dialog)? Version 26.616.51431 ### What subscription do you have? pro €225/month ### What platform is your computer? _No response_ ### What issue are you seeing? Codex silently refuses to load certain sites using the Chrome plugin. there seems to be a server-side blacklist of sites that Codex refuses to load. When you try and access one of these sites, the browser plugin throws an error: ``` Browser Use rejected this action due to browser security policy. Reason: Browser Use is not permitted on https://detail.1688.com. ``` these sites aren't malicious or don't seem to be against TOS or anything: normal e-commerce sites such as Taobao or 1688.com. futhermore, this isn't documented anywhere either. Philosophically, having a web browser that decides - server side - which websites it can and can't load, without any transparency on this, it's not great. I could (grudgingly) understand if the sites are malicious/pornographic/illegal/etc, but these are genuine huge e-commerce sites - the Western equivalent of blocking Amazon or Walmart. More broadly, silently blocking sites in a non-transparent/undocumented way doesn't feel right either. It seems like you ALSO can't even use Computer Use on Chrome if a tab is open from one of the \"non-permitted\" websites: ``` mcp__computer_use.get_app_state({ \"app\": \"Google Chrome\" }) // returns: [{\"type\":\"text\",\"text\":\"This session has been stopped because Computer Use is not allowed on the current browser URL. Stop your work and send a final message noting why the session has been ended. Note that Computer Use is not allowed on this URL even if the user navigates to it themselves.\"}] ``` Obviously I could monkey-patch around this by modifying the javascript plugin or computer use.... but that's not an okay workaround either. Computer use, Chrome, and the Browser plugin should just work on all (legal) sites. ### What steps can reproduce the bug? Feedback ID: 019ee97a-589a-7670-9b4c-a7eadac555ba ### What is the expected behavior? The built in plugins do not run a server-side check to see if users are permitted to look at a certain site or not. ### Additional information Codex investigated the issue further, a brief summary (before we get the clanker to attach a big slop comment of everything it found): - On every request, the Chrome plugin will make a request to `https://chatgpt.com/backend-api/aura/site_status`, if this endpoint returns something, the request will be blocked - chrome plugin code: `/Users//.codex/plugins/cache/openai-bundled/chrome/26.616.51431/scripts/browser-client.mjs:3234`", "url": "https://github.com/openai/codex/issues/29343", "createdAt": "2026-06-21T14:51:23Z", "updatedAt": "2026-08-13T09:46:50Z", "timestamp": "2026-08-13T09:46:50Z", "metrics": { "reactions": 1, "comments": 14 }, "labels": [ "bug", "app", "safety-check", "computer-use", "browser" ], "author": "joshp123", "state": "open", "assignees": [] }, { "id": "github:openai/codex:issue:29463", "source": "github", "group": "coding-agent-infrastructure", "project": "openai/codex", "kind": "issue", "title": "Windows Codex app continuously writes high-volume TRACE websocket logs to ~/.codex/logs_2.sqlite despite RUST_LOG=warn", "text": "## Summary On Windows, Codex Desktop continuously writes high-frequency `TRACE` logs into `~/.codex/logs_2.sqlite`, mainly from websocket/tungstenite internals, even though `RUST_LOG=warn` and analytics/OTel export are disabled in `~/.codex/config.toml`. This causes persistent SQLite/WAL writes and database growth. ## Environment - OS: Windows - Codex app package: `OpenAI.Codex_26.616.6631.0_x64__2p2nqsd0c76g0` - Codex app-server process: - `codex.exe app-server --analytics-default-enabled` - Database: - `C:\\Users\\\\.codex\\logs_2.sqlite` - WAL mode with `logs_2.sqlite-wal` ## Relevant config `~/.codex/config.toml` includes: ```toml [analytics] enabled = false [otel] exporter = \"none\" ``` Environment variable checks: ```text RUST_LOG Process = warn RUST_LOG User = unset RUST_LOG Machine = unset ``` ## Observed behavior After fully restarting Codex Desktop, `logs_2.sqlite` continues to receive high-frequency writes. A 28-second sample after restart showed: ```text max(id) increased by 573 logs_2.sqlite-wal continued updating row count stayed constant, indicating new rows are inserted while older rows are deleted ``` Recent 1000 inserted ids were dominated by: ```text TRACE log 839 rows INFO codex_otel.log_only 41 rows INFO codex_otel.trace_safe 40 rows TRACE codex_api::endpoint::responses_websocket 40 rows TRACE codex_api::sse::responses 40 rows ``` Latest `TRACE log` bodies include low-level websocket/tungstenite messages such as: ```text tokio-tungstenite ... compat.rs ... Read.with_context read -> poll_read tokio-tungstenite ... lib.rs ... WebSocketStream.with_context Parsed headers [...] WouldBlock ``` ## Impact - Continuous disk writes to SQLite/WAL - `logs_2.sqlite` growth and churn - Extra local storage usage - Potential performance and SSD wear concern - TRACE-level logs may capture more detailed internal request/response metadata than expected Before manual maintenance, the database was approximately: ```text logs_2.sqlite before VACUUM: 199,499,776 bytes logs_2.sqlite after VACUUM: 75,206,656 bytes ``` After reopening Codex, WAL growth resumed: ```text logs_2.sqlite-wal around 5 MB and still updating ``` ## Expected behavior With `RUST_LOG=warn`, `[analytics].enabled = false`, and `[otel].exporter = \"none\"`, Codex should not continuously persist high-volume `TRACE` websocket/tungstenite logs to the local SQLite log store during normal use. If local SQLite diagnostics intentionally retain TRACE records, there should be a documented configuration option to disable or reduce this verbosity. ## Reproduction steps 1. Start Codex Desktop on Windows. 2. Ensure: - `RUST_LOG=warn` - `[analytics].enabled = false` - `[otel].exporter = \"none\"` 3. Open or continue a Codex thread. 4. Inspect `~/.codex/logs_2.sqlite` and `~/.codex/logs_2.sqlite-wal`. 5. Sample `max(id)`, `level`, `target`, and WAL modification time over 20-30 seconds. 6. Observe continuous inserts of `TRACE log`, `codex_api::endpoint::responses_websocket`, and `codex_api::sse::responses`. ## Notes I avoided attaching the SQLite database directly because it may contain sensitive local diagnostic/session details.", "url": "https://github.com/openai/codex/issues/29463", "createdAt": "2026-06-22T18:13:11Z", "updatedAt": "2026-08-12T18:26:58Z", "timestamp": "2026-08-12T18:26:58Z", "metrics": { "reactions": 2, "comments": 11 }, "labels": [ "bug", "windows-os", "app", "config", "app-server", "performance" ], "author": "LeoZhu1999", "state": "open", "assignees": [] }, { "id": "github:openai/codex:issue:29510", "source": "github", "group": "coding-agent-infrastructure", "project": "openai/codex", "kind": "issue", "title": "Codex app-server can grow to 30-40 GB when local rollout history is huge", "text": "### Summary After updating/restarting Codex Desktop, the `codex app-server` process grew to tens of GB on a 16 GB macOS machine, causing extreme swap usage and memory pressure. Local evidence points to a pathological persisted rollout/session history interacting with app-server thread listing/resume/read paths. This report is intentionally sanitized: I am not attaching private transcript contents, only process metrics, file sizes, record counts, crash UI, and public repo code paths. ### Environment - Codex Desktop: `26.616.51431` build `4212` - Codex app Chromium framework: `149.0.7827.115` - macOS: `26.3` (`25.3.0`), arm64 - Physical memory: 16 GB - Repo inspected: `openai/codex` at `5f129a4703ceaf843e1cb6996bbf4a4f21225198` ### Observed impact - Activity Monitor initially showed `codex` at ~22.4 GB with ~15.34 GB swap. - A later screenshot showed the same `codex` process at ~39.05 GB with ~32.06 GB swap. - A live `footprint`/`vmmap` capture while the process was bad showed: - `codex [690]` physical footprint: ~30 GB - `phys_footprint_peak`: ~30 GB - `MALLOC_SMALL`: ~30 GB dirty - `vmmap`: writable regions total ~30.9 GB; ~28.9 GB swapped out - OpenClaw/node child processes were much smaller at the time; the growth was in `/Applications/Codex.app/Contents/Resources/codex app-server --analytics-default-enabled`. ### Crash screen The same failure shape also produced this Codex crash screen: ![Codex crash screen showing SIGKILL after opening pathological thread](https://files.catbox.moe/tbn9k3.png) Visible crash details: - `Codex crashed with the following error:` - `(code=null, signal=SIGKILL)` - Most recent error is a WARN from a slow SQL log insert: - `message`: `slow statement execution time exceeded alert threshold` - `summary`: `INSERT INTO logs (...) VALUES ...` - `rows_affected`: `31` - `rows_returned`: `0` - `elapsed`: about `1.343s` - `slow_threshold`: `1s` After a tool-level aborted read, the app-server PID had changed/restarted and was back around a few hundred MB RSS, which is consistent with the UI crash/reload path rather than a clean handled error. ### Thread-management API repro The Codex thread-management API can list both problematic threads, but reading the pathological one aborts/crashes: - `codex_app.list_threads(query=\"Restart Openclaw\")` succeeds and returns: - thread id: `019df821-2a2e-7a01-be45-04b76d73c715` - title: `Restart Openclaw` - status: `notLoaded` - cwd: `/Users/.../LaterAI` - `codex_app.list_threads(query=\"OpenClaw recovery root-fix\")` succeeds and returns: - thread id: `019ee577-5cd2-75d1-a997-ffb4bf6eeefd` - status: `notLoaded` - `codex_app.read_thread(threadId=\"019ee577-5cd2-75d1-a997-ffb4bf6eeefd\", turnLimit=1, includeOutputs=false)` succeeds, although it returns/truncates a very large single-turn summary. - `codex_app.read_thread(threadId=\"019df821-2a2e-7a01-be45-04b76d73c715\", turnLimit=1, includeOutputs=false)` returned `aborted`. This makes the repro more concrete: metadata listing works, a smaller huge recovery thread can be read, but reading the pathological 11.88 GiB `Restart Openclaw` rollout via the thread-management API aborts/crashes Codex. ### Local state correlated with the spike The local Codex state contains one extreme rollout/thread history outlier: - Rollout JSONL size: `12,754,101,031` bytes (~11.88 GiB) - Line count: `84,643` - Thread DB `tokens_used` for that thread: `1,985,738,719` - Another related recovery thread had `tokens_used = 40,431,073` - `~/.codex/sessions` total size: ~12 GB, dominated by the single rollout file. - `~/.codex/logs_2.sqlite`: ~222 MB plus ~63 MB WAL at time of inspection. Content-safe sampling of the huge JSONL: Head sample, first 20,000 lines: - response_item: 13,922 - event_msg: 5,526 - turn_context: 343 - session_meta: 175 - compacted: 34 - `token_count` events: 2,779 - largest sampled line: ~11.1 MB Tail sample, last 2,000 lines: - response_item: 1,502 - event_msg: 467 - turn_context: 17 - compacted: 14 - `token_count` events: 248 - largest sampled line: ~60.9 MB ### Suspected code paths These paths appear capable of loading or scanning large rollout histories without size/record caps. 1. `thread/read` with turns loads persisted history and builds API turns - `codex-rs/app-server/src/request_processors/thread_processor.rs` - `thread_read_response_inner` -> `read_thread_view` -> `load_persisted_thread_for_read(... include_turns ...)` - `load_persisted_thread_for_read` calls `thread_store.read_thread(... include_history: include_turns ...)` - When history is returned, it calls `build_api_turns_from_rollout_items(&history.items)`. 2. Thread store `include_history` loads the entire rollout into memory - `codex-rs/thread-store/src/local/read_thread.rs` - `attach_history_if_requested` calls `load_history_items(&path)`. - `load_history_items` calls `RolloutRecorder::load_rollout_items(path)` and stores all items in `StoredThreadHistory`. 3. `RolloutRecorder::load_rollout_items` is unbounded - `codex-rs/rollout/src/recorder.rs` - It streams lines from `open_rollout_line_reader`, parses each line, then does `items.push(item)` into a `Vec` with no file-size cap, record-count cap, byte budget, or cancellation/backpressure noted in the inspected code. - On an 11.88 GiB rollout with some 10-60 MB JSONL records, this can plausibly explain a 30-40 GB app-server footprint. 4. `thread/list` normally preserves scan-and-repair behavior unless state DB-only is requested - `codex-rs/app-server/src/request_processors/thread_processor.rs` accepts `use_state_db_only` but defaults it through from the client params. - `codex-rs/thread-store/src/local/list_threads.rs` calls `RolloutRecorder::list_threads` when `use_state_db_only` is false, and only calls `list_threads_from_state_db` when true. - The protocol schema notes that `useStateDbOnly` skips scanning JSONL rollouts to repair thread metadata, which suggests the default thread list path can still touch rollout files. - The list summary path appears more bounded than full history loading, but it is still part of the startup/listing hazard for pathological rollouts. ### Expected behavior A pathological local rollout should not be able to make the app-server consume tens of GB. Suggested guardrails: - Refuse, truncate, quarantine, or summarize-only any rollout above a sane byte/record threshold for UI list/read/resume operations. - Make `thread/list` use state DB-only by default in the desktop app when state DB is available, or repair in a bounded background job. - Make `thread/read include_turns=true` enforce a byte/record budget and return a clear error or partial/summarized history instead of loading the whole rollout into memory. - Add memory/size telemetry around rollout replay/list/repair paths. - Consider clamping or treating impossible token counts (for example ~2B tokens) as corrupt/outlier state. ### Reproduction shape I do not have a minimal synthetic repro yet, but the local state suggests this shape: 1. Have a very large rollout JSONL under `~/.codex/sessions` (observed: 11.88 GiB, 84,643 lines, individual lines up to ~60.9 MB). 2. Ensure state DB references the thread and contains an extreme token count. 3. Restart Codex Desktop. 4. Open the thread list and/or read/resume the pathological thread with turns/history included. 5. Observe `/Applications/Codex.app/Contents/Resources/codex app-server --analytics-default-enabled` memory grow to 30-40 GB and swap climb into tens of GB, or observe the app-server abort/crash with `SIGKILL`. ### What would help users immediately A small safe-mode/quarantine behavior would be very helpful: if Codex detects a rollout above a threshold during startup/list/read/resume, skip full replay, show a recoverable warning, and avoid loading that file into app-server memory.", "url": "https://github.com/openai/codex/issues/29510", "createdAt": "2026-06-23T00:39:12Z", "updatedAt": "2026-08-13T03:16:24Z", "timestamp": "2026-08-13T03:16:24Z", "metrics": { "reactions": 1, "comments": 5 }, "labels": [ "bug", "app", "app-server", "performance" ], "author": "ghitafilali", "state": "open", "assignees": [] }, { "id": "github:openai/codex:issue:29639", "source": "github", "group": "coding-agent-infrastructure", "project": "openai/codex", "kind": "issue", "title": "Browser Use Node REPL fails in Windows Desktop app with WSL workspace due to unmapped sandboxCwd", "text": "## Summary Browser Use / Node REPL does not work in the Codex Windows Desktop app when the agent is configured to run in WSL and the project lives on the WSL filesystem. The Desktop app auto-generates a `node_repl` MCP server that runs a Windows `node_repl.exe`, but tool calls send a Linux/WSL `sandboxCwd` URI (`file:///home/...`). The Windows-side Node REPL rejects that path as not being a local file URI. All paths below are anonymized. ## Environment - Codex Desktop app on Windows - Agent configured to run in WSL2 - Integrated terminal configured as WSL - WSL distro: Ubuntu 22.04 - Project path inside WSL: `/home//projects/` - Windows view of same project: `\\\\wsl.localhost\\Ubuntu-22.04\\home\\\\projects\\` - `CODEX_HOME` inside the WSL agent session: `/mnt/c/Users//.codex` - Codex CLI from `codex doctor`: `Codex Doctor v0.142.0 · linux-x86_64` - Desktop/browser runtime version visible in generated MCP env: `BROWSER_USE_CODEX_APP_VERSION=26.616.71553` - Browser Use plugin enabled Relevant config state: ```toml [desktop] runCodexInWindowsSubsystemForLinux = true integratedTerminalShell = \"wsl\" [plugins.\"browser-use@openai-bundled\"] enabled = true ``` ## Reproduction Steps 1. On Windows, configure Codex Desktop to run the agent in WSL. 2. Open a project located on the WSL filesystem, e.g. `/home//projects/`. 3. Enable the Browser Use plugin. 4. Start/restart Codex Desktop. 5. Inspect MCP configuration from the WSL agent session: ```bash codex mcp get node_repl ``` Codex Desktop auto-generates a user-level MCP server similar to: ```toml [mcp_servers.node_repl] command = \"/mnt/c/Users//AppData/Local/OpenAI/Codex/runtimes/cua_node//bin/node_repl.exe\" startup_timeout_sec = 120 [mcp_servers.node_repl.env] BROWSER_USE_AVAILABLE_BACKENDS = \"chrome\" CODEX_HOME = \"C:\\\\Users\\\\\\\\.codex\" CODEX_CLI_PATH = \"/usr/local/bin/codex\" WSLENV = \"...\" ``` 6. Trigger a Node REPL JS call, for example through Browser Use setup or directly via the exposed `node_repl/js` tool. ## Actual Behavior The Node REPL tool is visible, but every JS execution fails immediately: ```text tool call failed for `node_repl/js` Caused by: Mcp error: -32602: js: codex/sandbox-state-meta: sandboxCwd is not a local file URI: file:///home//projects/ ``` This blocks Browser Use entirely. The in-app browser cannot be automated from Codex in this setup. ## Expected Behavior When the Desktop app is configured to run the agent in WSL, Browser Use should work for WSL-hosted projects. Either: - the `node_repl` MCP process should run in the matching WSL/Linux environment, or - Codex should map the WSL sandbox cwd to a Windows-local/UNC path before passing it to a Windows-side `node_repl.exe`, e.g. `\\\\wsl.localhost\\Ubuntu-22.04\\home\\\\projects\\`, or - Browser Use should provision its internal Node REPL / backend in a way that does not mix Windows runtime expectations with Linux `file:///home/...` sandbox metadata. ## Additional Diagnostics `codex doctor --summary` from the WSL agent session confirms the agent/runtime is Linux/WSL: ```text Codex Doctor v0.142.0 · linux-x86_64 Environment: Ubuntu 22.04, WSL_DISTRO_NAME present Configuration: config loaded from /mnt/c/Users//.codex/config.toml MCP: 1 server (1 stdio) Sandbox: restricted fs + restricted network ``` `codex mcp get node_repl` confirms the generated MCP server uses a Windows executable: ```text command: /mnt/c/Users//AppData/Local/OpenAI/Codex/runtimes/cua_node//bin/node_repl.exe cwd: - ``` I also tested adding an explicit UNC cwd to the generated MCP block: ```toml cwd = '\\\\wsl.localhost\\Ubuntu-22.04\\home\\\\projects\\' ``` Codex accepted and displayed that cwd via `codex mcp get node_repl`, but the tool still failed with the same `sandboxCwd is not a local file URI: file:///home/...` error. After restarting Codex Desktop, the generated MCP block was overwritten again and the explicit `cwd` was removed. I also tested disabling the Chrome and Computer Use plugins while keeping Browser Use enabled. Codex Desktop still regenerated the same Windows `node_repl.exe` MCP block with `BROWSER_USE_AVAILABLE_BACKENDS = \"chrome\"`. I did not use `--disable-sandbox`; this report is about the default sandboxed path.", "url": "https://github.com/openai/codex/issues/29639", "createdAt": "2026-06-23T14:30:46Z", "updatedAt": "2026-08-12T18:05:33Z", "timestamp": "2026-08-12T18:05:33Z", "metrics": { "reactions": 3, "comments": 15 }, "labels": [ "bug", "windows-os", "mcp", "tool-calls", "app", "browser" ], "author": "atlantho", "state": "open", "assignees": [] }, { "id": "github:openai/codex:issue:29719", "source": "github", "group": "coding-agent-infrastructure", "project": "openai/codex", "kind": "issue", "title": "Severe session sync issues between tui/desktop/mobile", "text": "### What issue are you seeing? Sessions don't stay in sync when used across cli/desktop/mobile. ### What steps can reproduce the bug? 1. Start cli, launch some subagents 2. While running/once finished, send followup/steer from mobile (android) remotely connected to your host 3. Check cli and see no update made to the session 4. Check codex desktop && vscode extension, and you might see updates for the session, but also might not ### What is the expected behavior? Sending a message from one client should trigger updates to other sessions, ideally when messages are sent, but at the very least when responses are sent (a little lag is fine, but not completely lost msgs/tui never updating). ### Additional information Codex Feedback/thread ID: 019ef531-0938-7220-afbf-d5dbb802ba9a", "url": "https://github.com/openai/codex/issues/29719", "createdAt": "2026-06-23T21:04:48Z", "updatedAt": "2026-08-13T10:49:39Z", "timestamp": "2026-08-13T10:49:39Z", "metrics": { "reactions": 1, "comments": 2 }, "labels": [ "bug", "extension", "TUI", "CLI", "app", "session" ], "author": "RickDavis404", "state": "open", "assignees": [] }, { "id": "github:openai/codex:issue:29958", "source": "github", "group": "coding-agent-infrastructure", "project": "openai/codex", "kind": "issue", "title": "Windows: WebSocket transport times out with respect_system_proxy, works with HTTP_PROXY/HTTPS_PROXY", "text": "### What version of the Codex App are you using (From “About Codex” dialog)? 0.142.1 ### What subscription do you have? plus ### What platform is your computer? Windows 10 ### What issue are you seeing? With `network_proxy` and `respect_system_proxy` enabled on Windows, Codex can use the system proxy for HTTPS requests, but WebSocket transport times out and falls back to HTTPS: ```text Falling back from WebSockets to HTTPS transport. request timed out ``` If I set `HTTP_PROXY` and `HTTPS_PROXY` to the same proxy, WebSocket transport works correctly. It seems WebSocket transport does not fully respect the Windows system proxy configuration. ### What steps can reproduce the bug? Behavior: - HTTPS requests work through Windows system proxy. - WebSocket transport times out and falls back to HTTPS. When HTTP_PROXY/HTTPS_PROXY are set to the same proxy: - WebSocket transport works correctly. It appears that WebSocket transport does not fully honor the Windows system proxy resolver. ### What is the expected behavior? _No response_ ### Additional information _No response_", "url": "https://github.com/openai/codex/issues/29958", "createdAt": "2026-06-25T02:27:14Z", "updatedAt": "2026-08-13T07:16:27Z", "timestamp": "2026-08-13T07:16:27Z", "metrics": { "reactions": 0, "comments": 5 }, "labels": [ "bug", "windows-os", "app", "connectivity" ], "author": "fei1025", "state": "open", "assignees": [] }, { "id": "github:openai/codex:issue:30038", "source": "github", "group": "coding-agent-infrastructure", "project": "openai/codex", "kind": "issue", "title": "Support configurable Git providers and credentials for self-hosted Git servers", "text": "### What variant of Codex are you using? App ### What feature would you like to see? Codex should support alternate Git platforms through a configurable Git provider section in settings: `Settings -> Coding -> Git` Users should be able to add Git hosts beyond `github.com`, including self-hosted instances, and provide the
credentials Codex needs to resolve repository, branch, issue, pull request, and merge request context. Examples: * [GitLab.com]() * self-hosted GitLab CE / EE * Forgejo * Gitea * other Git-compatible hosts where API support can be added over time ### Additional information There are existing requests for this in related areas: * openai/codex#8156 requested broader support for platforms other than GitHub, including GitLab, Gitea, Gogs, and Forgejo. * openai/codex#26963 asks for GitLab Merge Request links in the Codex App sidebar, including support for self-hosted GitLab. Codex currently has first-class GitHub workflow awareness, but many teams use self-hosted or non-GitHub Git platforms.", "url": "https://github.com/openai/codex/issues/30038", "createdAt": "2026-06-25T12:03:05Z", "updatedAt": "2026-08-12T17:53:40Z", "timestamp": "2026-08-12T17:53:40Z", "metrics": { "reactions": 5, "comments": 2 }, "labels": [ "enhancement", "auth", "app", "config" ], "author": "imperius361", "state": "open", "assignees": [] }, { "id": "github:openai/codex:issue:30043", "source": "github", "group": "coding-agent-infrastructure", "project": "openai/codex", "kind": "issue", "title": "macOS GUI apps launched from Codex sandbox abort at _RegisterApplication", "text": "### Description Launching macOS GUI applications from a Codex sandboxed shell can crash the target app immediately with `SIGABRT` at `_RegisterApplication`. This appears broader than a single app-specific CLI integration. I reproduced it with both Google Chrome and LibreOffice, and it is similar in shape to openai/codex#13706, but these repros do not depend on Obsidian's CLI/socket behavior. ### Environment * Codex Desktop * macOS 26.5.1 (25F80) * Apple Silicon Mac, model code observed in crash report: `Mac17,2` * Sandbox mode: workspace-write / default sandboxed command execution * Chrome: reproduced with `149.0.7827.158`; after clean reinstall, reproduced again with `149.0.7827.197` * LibreOffice: `26.2.4.2` ### Reproduction: Chrome From a Codex sandboxed shell, run: ```bash /Applications/Google\\ Chrome.app/Contents/MacOS/Google\\ Chrome \\ --headless=new \\ --user-data-dir=/private/tmp/chrome-codex-smoke \\ --no-first-run \\ --no-default-browser-check \\ --disable-gpu \\ --dump-dom about:blank ``` Observed result: * Command exits with code `134` * Crash report shows `EXC_CRASH (SIGABRT)` / `Abort trap: 6` * Crash report parent/responsible process is Codex/codex * Faulting main-thread frames include: ```text abort ___RegisterApplication_block_invoke _dispatch_once_callout _RegisterApplication TransformProcessType ChromeMain main ``` Running the same Chrome launch outside the sandbox via elevated execution / LaunchServices succeeds. A headless smoke test returned: ```json { \"Browser\": \"Chrome/149.0.7827.197\", \"Protocol-Version\": \"1.3\" } ``` ### Reproduction: LibreOffice From a Codex sandboxed shell, run: ```bash soffice --headless \\ -env:UserInstallation=file:///private/tmp/libreoffice-smoke-profile \\ --convert-to pdf \\ --outdir /private/tmp \\ /private/tmp/libreoffice-smoke.txt ``` Observed result: * Command exits with code `134` * Crash report shows `EXC_CRASH (SIGABRT)` / `Abort trap: 6` * Crash report parent/responsible process is Codex/codex * Faulting main-thread frames include: ```text abort ___RegisterApplication_block_invoke _dispatch_once_callout _RegisterApplication GetCurrentProcess -[NSApplication init] +[NSApplication sharedApplication] create_SalInstance CreateSalInstance InitVCL soffice_main main ``` Running the same LibreOffice conversion outside the sandbox succeeds: ```text convert /private/tmp/libreoffice-smoke.txt as a Writer document -> /private/tmp/libreoffice-smoke.pdf using filter : writer_pdf_Export ``` ### Expected behavior Codex should not make these failures look like app crashes caused by Chrome/LibreOffice themselves. Ideally Codex would either: * detect that the command is launching a macOS GUI app and prompt/escalate to run it outside the sandbox, or * fail early with a clear sandbox limitation message rather than letting the GUI app abort in macOS app registration. ### Notes This looks related to openai/codex#13706, but the Chrome and LibreOffice repros suggest the problem is not limited to Obsidian's CLI behavior. The common failure point is macOS app registration from a Codex-spawned sandboxed process.", "url": "https://github.com/openai/codex/issues/30043", "createdAt": "2026-06-25T12:52:07Z", "updatedAt": "2026-08-13T16:02:52Z", "timestamp": "2026-08-13T16:02:52Z", "metrics": { "reactions": 2, "comments": 6 }, "labels": [ "bug", "sandbox", "app" ], "author": "ElninoZhong", "state": "open", "assignees": [] }, { "id": "github:openai/codex:issue:30408", "source": "github", "group": "coding-agent-infrastructure", "project": "openai/codex", "kind": "issue", "title": "MCP server processes leak: per-thread processes never cleaned up (9+ GB RSS)", "text": "## Bug description Codex app-server spawns a full set of global MCP server processes for each new thread/conversation, but **never kills them when threads are archived or closed**. Over time, orphaned MCP processes accumulate unboundedly. ## Environment - Codex Desktop: 0.142.3 (macOS, Apple Silicon) - OS: macOS 15.x, 64 GB RAM ## Steps to reproduce 1. Configure global MCP servers in `~/.codex/config.toml` (e.g. `playwright`, `davinci-resolve`, `node_repl`) 2. Open Codex Desktop, create ~25 threads over a session 3. Close/archive threads as normal 4. Check process list ## Expected behavior MCP server processes should be cleaned up when the owning thread is closed or archived. At most one set of MCP processes should exist per actively-used server. ## Actual behavior After 25 threads, observed **133 orphaned MCP processes** consuming **~9.3 GB RSS**: | MCP Server | Orphaned Processes | RSS | |---|---|---| | `playwright` (npm + node) | 52 | 2.9 GB | | `davinci-resolve` (python) | 26 | 3.5 GB | | `node_repl` | 26 | 266 MB | | npm exec wrappers | 29 | 2.6 GB | All processes had PPID = app-server PID. The app-server holds them indefinitely. ## Root cause The app-server does not track which MCP processes belong to which thread, and has no lifecycle management to kill MCP processes when threads end. There is also no `idle_timeout`, `reuse`, or `shared` config option for MCP servers. ## Workaround - Manually kill orphaned processes: `pkill -P -f \"playwright-mcp|davinci-resolve\"` - Remove rarely-used MCP servers from global config and add them per-project instead ## Suggested fix - Track MCP process ownership per-thread - Kill MCP processes when the owning thread is closed/archived - Alternatively, add a `shared` or `reuse` mode so all threads share a single MCP process instance - Consider an `idle_timeout` option to auto-kill MCP processes after N minutes of no use", "url": "https://github.com/openai/codex/issues/30408", "createdAt": "2026-06-28T03:40:13Z", "updatedAt": "2026-08-13T02:37:01Z", "timestamp": "2026-08-13T02:37:01Z", "metrics": { "reactions": 8, "comments": 29 }, "labels": [ "bug", "mcp", "app", "app-server", "performance" ], "author": "kkkayye", "state": "open", "assignees": [] }, { "id": "github:openai/codex:issue:30440", "source": "github", "group": "coding-agent-infrastructure", "project": "openai/codex", "kind": "issue", "title": "Codex uses bundled pnpm instead of host toolchain", "text": "### What version of the Codex App are you using (From “About Codex” dialog)? 26.623.42026 ### What subscription do you have? Pro ### What platform is your computer? Darwin 24.6.0 arm64 arm ### What issue are you seeing? Codex is consistently failing to run my build script because that script invokes `pnpm install`. As per its own diagnosis: - My local projects uses PNPM v10 - Codex comes bundled with PNPM v11 in `~/.cache/codex-runtimes/codex-primary-runtime/dependencies/bin/pnpm` - When running the build script, Codex uses the bundled one, leading to failure to resolve dependencies, whereas the build script is run fine in any local terminal ### What steps can reproduce the bug? 1. Create a pnpm v10 project with dependencies in package.json 2. Run `pnpm install` in **terminal** to install the dependencies 3. Create a js script ```javascript import { spawn } from \"node:child_process\"; const child = spawn(\"pnpm\", [\"install\"], { cwd: process.cwd(), stdio: [\"ignore\", \"pipe\", \"pipe\"], }); child.on(\"close\", (code) => { process.exit(code ?? 1); }); ``` 4. Ask Codex (with pnpm v11 bundled) to run `node script.mjs` inside project dir ### What is the expected behavior? Codex should use my local pnpm binary, and ask for permission elevation when needed. In fact, using this to run the build script is fine: `PATH=\"path-to-my-local-nodejs/bin:$PATH\" CI=true node script.mjs` ### Additional information _No response_", "url": "https://github.com/openai/codex/issues/30440", "createdAt": "2026-06-28T10:58:46Z", "updatedAt": "2026-08-13T06:15:23Z", "timestamp": "2026-08-13T06:15:23Z", "metrics": { "reactions": 28, "comments": 21 }, "labels": [ "bug", "sandbox", "app" ], "author": "kkaatii", "state": "open", "assignees": [] }, { "id": "github:openai/codex:issue:30484", "source": "github", "group": "coding-agent-infrastructure", "project": "openai/codex", "kind": "issue", "title": "Codex Desktop no longer shows file tree, review pane, or branch UI despite Git being detected", "text": "## Summary Codex Desktop stopped showing the file tree / review pane entry points / current branch UI for local Git projects. This appears to be a Desktop UI regression: Git, GitHub auth, the Codex CLI, and the Codex app backend all still detect the repositories correctly. The issue started recently, within the last couple of days. It affects all Codex Desktop projects on this machine, not just one repository. ## Environment - Codex Desktop: 26.623.42026 - Build: 4514 - Bundled Codex CLI: 0.142.3 - macOS: 15.7.4, arm64 - Git: 2.53.0 - GitHub CLI: 2.95.0 - Account has GitHub CLI auth and Codex GitHub connector access ## Expected behavior For projects inside a Git repository, Codex Desktop should expose the file tree / Git branch context / review pane so changes can be inspected in the UI. This matches the Codex app docs: the review pane works for projects inside a Git repository and reflects the Git repo state. ## Actual behavior The Desktop UI does not show: - file tree / project tree - review pane option - current branch / Git repo indicator This happens even though the same project is a valid Git repo and Codex backend state includes branch/origin metadata. ## Diagnostics already performed Local Git and repo state are healthy: ```text git status --short --branch ## master...origin/master HEAD == master == origin/master ``` GitHub / gh auth are healthy: ```text gh auth status -h github.com ✓ Logged in to github.com account Token scopes: gist, read:org, repo, workflow ``` Codex doctor is clean: ```text Codex Doctor v0.142.3 · macos-aarch64 17 ok · 1 idle · 1 notes · 0 warn · 0 fail ok ``` The Codex state DB still has Git metadata for the active thread: ```text thread cwd= git_branch=master git_origin_url= git_sha= ``` The Desktop config does not appear to disable Git/review. It includes: ```toml [desktop] git-show-sidebar-pr-icons = true ``` After a full profile reset, logs still show Git watchers running and origins being detected: ```text info [git-repo-watcher] Starting git repo watcher info [git] [git-origins] worker-complete ... originCount=... ``` ## Recovery attempts already tried - Restarted Codex Desktop normally - Found multiple stale Codex Desktop processes and terminated them - Reset persisted UI state under `~/.codex/.codex-global-state.json` with backup - Reset Codex Desktop Electron profile by moving `~/Library/Application Support/Codex` to a timestamped backup - Cleared Codex Desktop session storage as part of the profile reset - Reopened Codex Desktop cleanly with only one main Codex process running - Confirmed `~/.codex` state, memories, sessions, and SQLite DB integrity remained OK - Confirmed GitHub CLI and GitHub connector access remained OK Despite all of the above, the UI still does not show tree/review/branch controls. ## Notes This does not appear to be a repository issue, GitHub permission issue, or CLI issue. It looks isolated to Codex Desktop UI rendering/feature exposure after a recent update.", "url": "https://github.com/openai/codex/issues/30484", "createdAt": "2026-06-28T21:05:23Z", "updatedAt": "2026-08-13T06:39:23Z", "timestamp": "2026-08-13T06:39:23Z", "metrics": { "reactions": 0, "comments": 9 }, "labels": [ "bug", "code-review", "app" ], "author": "Aleopazo", "state": "open", "assignees": [] }, { "id": "github:openai/codex:issue:30573", "source": "github", "group": "coding-agent-infrastructure", "project": "openai/codex", "kind": "issue", "title": "Support first-class Windows-to-Windows Codex App pairing and remote control", "text": "### What variant of Codex are you using? Codex App on Windows / Windows-to-Windows usage ### What feature would you like to see? Please add first-class support for connecting two Codex desktop apps on Windows, so one Windows machine can act as the Codex host and another Windows machine can control it through the official Codex App experience. Desired behavior: - Pair two Windows Codex Apps through a supported flow, for example QR code, device code, or signed account-based pairing. - Let the control machine browse the host machine's projects, threads, plans, command output, diffs, approvals, and file changes. - Keep the host machine as the only real execution environment: files, credentials, plugins, `.codex` state, git worktrees, and tool execution stay on the host. - Do not require users to copy `.codex`, auth files, SQLite/WAL state, or tokens between machines. - Avoid requiring users to manually build a custom web gateway around `codex app-server`. - Support Windows-native environments, including cases where RDP/SSH setup is unavailable, unreliable, or too much overhead. - Include reliable reconnect, host naming, stale host cleanup, and clear status/error messages. - Provide a safe transport model: private relay, account-mediated pairing, or documented VPN/mesh-network mode, without exposing `codex app-server` directly to LAN/public networks. ### Additional information The current workaround is operationally heavy. In my case, I had to build a custom Windows remote console project: - A Node gateway runs on the real Codex host. - The gateway launches `codex app-server` over stdio. - A browser on the second machine talks to that gateway. - Tailscale Serve is used for cross-machine access. - Extra care is required not to expose `.codex/auth.json`, SQLite/WAL files, tokens, or app-server internals. This works as a workaround, but it is too much infrastructure for a normal user who simply wants to use one Windows Codex environment from another Windows computer. There are already many Windows remote/app-server issues, but this request is specifically for a polished first-party Windows-to-Windows Codex App connection flow rather than asking users to assemble their own app-server gateway, RDP fallback, SSH setup, or Tailscale wrapper.", "url": "https://github.com/openai/codex/issues/30573", "createdAt": "2026-06-29T12:53:11Z", "updatedAt": "2026-08-13T06:41:21Z", "timestamp": "2026-08-13T06:41:21Z", "metrics": { "reactions": 1, "comments": 2 }, "labels": [ "enhancement", "windows-os", "app", "remote" ], "author": "falyx6851-byte", "state": "open", "assignees": [] }, { "id": "github:openai/codex:issue:30745", "source": "github", "group": "coding-agent-infrastructure", "project": "openai/codex", "kind": "issue", "title": "Codex TUI scrollback rows can disappear after inline viewport height changes", "text": "## Summary Codex TUI can lose finalized assistant message rows from terminal scrollback after the inline bottom viewport changes height during or after streaming. The persisted conversation and Codex-rendered rows are complete, but the terminal document/scrollback can omit a small number of rows until a real terminal resize forces transcript-backed reflow. The issue was reproduced on Windows Terminal at default geometry. My local setup uses a public patched Windows Terminal fork (\"PWT\") for automation, mainly to drive `wt send-input` and repeatable captures. The user-visible failure is still ordinary Windows Terminal/Codex TUI behavior: maximizing the window repairs the text because Codex replays scrollback from transcript source during terminal resize. ## Environment - OS: Windows 10 21H2 - Terminal: Windows Terminal; local patched WT/PWT fork used for automation and repeatable captures - Codex source: `cfead68e5d3984b247cf0758e3e53b19165de848` - Commit: `[codex] disable Nagle on Rendezvous WebSockets (#30269)` - Dev build: `codex-cli 0.0.0` - Repro geometry observed in traces: `120x30` ## Reproduction Use an assistant message containing this section: ```markdown - Gateway host updated - Patched installed host-current using the supported patch-host flow. - New host process: PID 11548. - New host build: 1.0.0+db20263cf34f7a05de4fe00616499ed6dd63fa7a. - Existing Codex CLI sessions were not restarted. ``` In a default-height Windows Terminal Codex session, ask Codex to print the fixture exactly. ## Expected Once Codex has emitted finalized assistant rows into scrollback, app-internal bottom pane height changes should not cause previously emitted rows to disappear. If the inline viewport grows or shrinks over emitted history, Codex should replay scrollback from transcript source, as it already does for terminal resize. ## Actual Final default-height UIA `document_range` showed: - `Gateway host updated` - `New host build...` - `Existing Codex CLI sessions...` It omitted: - `Patched installed host-current...` - `New host process: PID 11548.` Maximize/restore made the missing rows reappear. ## Evidence Evidence pack files: - `screenshots/00-streaming-gateway-bullets-visible.png` - `screenshots/01-finalized-gateway-bullets-clipped.png` - `screenshots/01-failing-default-height-final.png` - `uia-excerpts/01-failing-default-height-final.txt` - `trace-excerpts/01-failing-marker-rows.tsv` - `screenshots/02-resize-repaired-after-maximize.png` - `uia-excerpts/02-resize-repaired-after-maximize.txt` - `trace-excerpts/02-failing-resize-reflow-repair.tsv` - `screenshots/03-fixed-default-height-final.png` - `uia-excerpts/03-fixed-default-height-final.txt` - `trace-excerpts/03-fixed-height-change-reflow.tsv` - `screenshots/04-control-minimal-ansi-replay.png` - `uia-excerpts/04-control-minimal-ansi-replay.txt` Codex trace from the failing run proves the missing rows reached terminal insertion: ```text insert_history_row markers=gateway_header text= - Gateway host updated insert_history_row markers=patched_host text= - Patched installed host-current using the supported patch-host flow. insert_history_row markers=host_pid text= - New host process: PID 11548. insert_history_row markers=host_build text= - New host build: 1.0.0+db20263cf34f7a05de4fe00616499ed6dd63fa7a. insert_history_row markers=existing_sessions text= - Existing Codex CLI sessions were not restarted. ``` The same run showed resize repair after maximize because transcript-backed reflow replayed the rows. The key visual evidence is the original screenshot pair captured from the live session: - while the response was still rendering, all four child bullets under `Gateway host updated` were visible; - after final render, only `New host build` and `Existing Codex CLI sessions` remained visible in that section. ## Relationship to #27644 GitHub flagged #27644 as a potential duplicate. This report appears related to the same broad class of disappearing transcript/scrollback rows that repair after resize. The difference is that this reproduction is from Windows Terminal/PWT rather than an xterm.js host, and the local diagnostics point at app-internal inline viewport height changes needing transcript-backed reflow. If maintainers consider this the same root cause as #27644, this issue can be merged there; otherwise this should help track the Windows Terminal/PWT and viewport-height-change variant separately. ## Root Cause Hypothesis Codex resize reflow currently handles terminal width/height changes, but app-internal inline viewport height changes can also clear or shift rows where terminal scrollback history was emitted. When the bottom viewport height changes over emitted history, Codex needs to schedule a source-backed transcript reflow on the next frame. Otherwise rows can be lost until a real terminal resize triggers the existing reflow path. ## Candidate Fix Track the last desired inline viewport height in `App`. After drawing a frame where that desired height changes and scrollback history has already been emitted, schedule immediate transcript reflow. If the change happens during streaming, mark it as stream-time reflow so consolidation can still repair with source-backed finalized cells. Also keep the viewport bottom-aligned when it shrinks after having been bottom-aligned. Patch sketch: ```rust last_inline_viewport_height: Option, ``` ```rust let desired_height = self.chat_widget.desired_height(tui.terminal.size()?.width); let previous_height = self.last_inline_viewport_height.replace(desired_height); let viewport_height_changed = previous_height.is_some_and(|previous| previous != desired_height); tui.draw_with_resize_reflow(desired_height, |frame| { // existing render })?; if viewport_height_changed && self.has_emitted_history_lines && self.overlay.is_none() { if self.should_mark_reflow_as_stream_time() { self.transcript_reflow.mark_resize_requested_during_stream(); } self.transcript_reflow.schedule_immediate(); tui.frame_requester().schedule_frame(); } ``` ```rust let viewport_height_shrank = area.height < previous_area.height; // ... } else if viewport_was_bottom_aligned && (terminal_height_grew || viewport_height_shrank) { area.y = size.height - area.height; } ``` ## Validation Passed: ```text cargo test -p codex-tui streaming::controller::tests::affected_fixture_streamed_rows_match_finalized_markdown_rows -- --nocapture ``` Live validation: - failing baseline reproduced at default height; - required-final-reflow-only candidate did not fix; - raw-insert-only candidate did not fix; - bottom-align-only candidate did not fix; - app-level height-change reflow candidate fixed the stronger `document_range` row loss at default height. ## Attachments I have attached a sanitized public evidence bundle plus the key screenshots. The inline screenshots are ordered as: 1. all gateway bullets visible while the response was still rendering; 2. finalized response with two gateway child bullets missing; 3. maximize/restore repair showing the missing rows restored. The bundle contains the README, hash index, sensitivity review, UIA excerpts, trace excerpts, and the candidate fix sketch. [codex-message-truncation-windows-terminal-evidence-20260630.zip](https://github.com/user-attachments/files/29516419/codex-message-truncation-windows-terminal-evidence-20260630.zip) **1. Streaming: all gateway bullets visible** \"Streaming **2. Finalized: two gateway bullets missing** \"Finalized **3. Resize repair: missing rows restored after maximize** \"Resize-repaired ## Notes The local diagnostic trace helper should not be upstreamed as-is. A PR should keep only the minimal fix and focused tests for app-internal inline viewport height changes over emitted history.", "url": "https://github.com/openai/codex/issues/30745", "createdAt": "2026-06-30T17:16:53Z", "updatedAt": "2026-08-12T22:37:17Z", "timestamp": "2026-08-12T22:37:17Z", "metrics": { "reactions": 3, "comments": 5 }, "labels": [ "bug", "windows-os", "TUI", "CLI" ], "author": "laffo16", "state": "open", "assignees": [] }, { "id": "github:openai/codex:issue:30829", "source": "github", "group": "coding-agent-infrastructure", "project": "openai/codex", "kind": "issue", "title": "codex-windows-sandbox-setup.exe not found by CLI setup after clean install due to bin junction", "text": "### What version of Codex CLI is running? codex-cli 0.142.5 ### What subscription do you have? Enterprise ### Which model were you using? gpt-5.5 ### What platform is your computer? Microsoft Windows NT 10.0.28000.0 x64 ### What terminal emulator and version are you using (if applicable)? _No response_ ### Codex doctor report ```json { \"schemaVersion\": 1, \"generatedAt\": \"1782914399s since unix epoch\", \"overallStatus\": \"ok\", \"codexVersion\": \"0.142.5\", \"checks\": { \"app_server.status\": { \"id\": \"app_server.status\", \"category\": \"app-server\", \"status\": \"ok\", \"summary\": \"background server is not running\", \"details\": { \"control socket\": \"C:\\\\Users\\\\vboxuser\\\\.codex\\\\app-server-control\\\\app-server-control.sock\", \"daemon state dir\": \"C:\\\\Users\\\\vboxuser\\\\.codex\\\\app-server-daemon\", \"mode\": \"ephemeral\", \"pid file\": \"C:\\\\Users\\\\vboxuser\\\\.codex\\\\app-server-daemon\\\\app-server.pid (missing)\", \"settings\": \"C:\\\\Users\\\\vboxuser\\\\.codex\\\\app-server-daemon\\\\settings.json (missing)\", \"status\": \"not running\", \"update-loop pid file\": \"C:\\\\Users\\\\vboxuser\\\\.codex\\\\app-server-daemon\\\\app-server-updater.pid (missing)\" }, \"remediation\": null, \"durationMs\": 0 }, \"auth.credentials\": { \"id\": \"auth.credentials\", \"category\": \"auth\", \"status\": \"ok\", \"summary\": \"auth is configured\", \"details\": { \"auth file\": \"C:\\\\Users\\\\vboxuser\\\\.codex\\\\auth.json\", \"auth storage mode\": \"File\", \"stored API key\": \"false\", \"stored ChatGPT tokens\": \"true\", \"stored agent identity\": \"false\", \"stored auth mode\": \"chatgpt\" }, \"remediation\": null, \"durationMs\": 0 }, \"config.load\": { \"id\": \"config.load\", \"category\": \"config\", \"status\": \"ok\", \"summary\": \"config loaded\", \"details\": { \"CODEX_HOME\": \"C:\\\\Users\\\\vboxuser\\\\.codex\", \"config.toml\": \"C:\\\\Users\\\\vboxuser\\\\.codex\\\\config.toml\", \"config.toml parse\": \"ok\", \"cwd\": \"C:\\\\Users\\\\vboxuser\", \"enabled feature flags\": \"\", \"feature flag overrides\": \"none\", \"feature flags enabled\": \"33\", \"log dir\": \"C:\\\\Users\\\\vboxuser\\\\.codex\\\\log\", \"mcp servers\": \"0\", \"model\": \"\", \"model provider\": \"openai\", \"sqlite home\": \"C:\\\\Users\\\\vboxuser\\\\.codex\" }, \"remediation\": null, \"durationMs\": 0 }, \"git.environment\": { \"id\": \"git.environment\", \"category\": \"git\", \"status\": \"ok\", \"summary\": \"git executable not found\", \"details\": { \"PATH git entries\": \"0\", \"repo detected\": \"false\", \"selected git\": \"not found\" }, \"remediation\": null, \"durationMs\": 5 }, \"installation\": { \"id\": \"installation\", \"category\": \"install\", \"status\": \"ok\", \"summary\": \"installation looks consistent\", \"details\": { \"PATH codex #1\": \"C:\\\\Users\\\\vboxuser\\\\AppData\\\\Local\\\\Programs\\\\OpenAI\\\\Codex\\\\bin\\\\codex.exe\", \"current executable\": \"C:\\\\Users\\\\vboxuser\\\\AppData\\\\Local\\\\Programs\\\\OpenAI\\\\Codex\\\\bin\\\\codex.exe\", \"install context\": \"standalone (windows, package C:\\\\Users\\\\vboxuser\\\\.codex\\\\packages\\\\standalone\\\\releases\\\\0.142.5-x86_64-pc-windows-msvc, bin C:\\\\Users\\\\vboxuser\\\\.codex\\\\packages\\\\standalone\\\\releases\\\\0.142.5-x86_64-pc-windows-msvc\\\\bin, resources C:\\\\Users\\\\vboxuser\\\\.codex\\\\packages\\\\standalone\\\\releases\\\\0.142.5-x86_64-pc-windows-msvc\\\\codex-resources, path C:\\\\Users\\\\vboxuser\\\\.codex\\\\packages\\\\standalone\\\\releases\\\\0.142.5-x86_64-pc-windows-msvc\\\\codex-path)\", \"managed by bun\": \"false\", \"managed by npm\": \"false\", \"managed package root\": \"not set\" }, \"remediation\": null, \"durationMs\": 75 }, \"mcp.config\": { \"id\": \"mcp.config\", \"category\": \"mcp\", \"status\": \"ok\", \"summary\": \"no MCP servers configured\", \"details\": {}, \"remediation\": null, \"durationMs\": 0 }, \"network.env\": { \"id\": \"network.env\", \"category\": \"network\", \"status\": \"ok\", \"summary\": \"network-related environment looks readable\", \"details\": { \"proxy env vars\": \"none\" }, \"remediation\": null, \"durationMs\": 0 }, \"network.provider_reachability\": { \"id\": \"network.provider_reachability\", \"category\": \"reachability\", \"status\": \"ok\", \"summary\": \"active provider endpoints are reachable over HTTP\", \"details\": { \"ChatGPT base URL\": \"https://chatgpt.com/backend-api/ reachable (HTTP 403)\", \"reachability mode\": \"ChatGPT auth\" }, \"remediation\": null, \"durationMs\": 102 }, \"network.websocket_reachability\": { \"id\": \"network.websocket_reachability\", \"category\": \"websocket\", \"status\": \"ok\", \"summary\": \"Responses WebSocket handshake succeeded\", \"details\": { \"DNS\": \"2 IPv4, 2 IPv6, first IPv4\", \"auth mode\": \"chatgpt\", \"connect timeout\": \"15000 ms\", \"endpoint\": \"wss://chatgpt.com/backend-api/\", \"handshake result\": \"HTTP 101 Switching Protocols\", \"model provider\": \"openai\", \"models etag present\": \"true\", \"provider name\": \"OpenAI\", \"proxy env vars\": \"none\", \"reasoning header\": \"false\", \"server model present\": \"false\", \"supports websockets\": \"true\", \"wire API\": \"responses\" }, \"remediation\": null, \"durationMs\": 568 }, \"runtime.provenance\": { \"id\": \"runtime.provenance\", \"category\": \"runtime\", \"status\": \"ok\", \"summary\": \"running standalone on windows-x86_64\", \"details\": { \"commit\": \"unknown\", \"current executable\": \"C:\\\\Users\\\\vboxuser\\\\AppData\\\\Local\\\\Programs\\\\OpenAI\\\\Codex\\\\bin\\\\codex.exe\", \"install method\": \"standalone (windows, package C:\\\\Users\\\\vboxuser\\\\.codex\\\\packages\\\\standalone\\\\releases\\\\0.142.5-x86_64-pc-windows-msvc, bin C:\\\\Users\\\\vboxuser\\\\.codex\\\\packages\\\\standalone\\\\releases\\\\0.142.5-x86_64-pc-windows-msvc\\\\bin, resources C:\\\\Users\\\\vboxuser\\\\.codex\\\\packages\\\\standalone\\\\releases\\\\0.142.5-x86_64-pc-windows-msvc\\\\codex-resources, path C:\\\\Users\\\\vboxuser\\\\.codex\\\\packages\\\\standalone\\\\releases\\\\0.142.5-x86_64-pc-windows-msvc\\\\codex-path)\", \"platform\": \"windows-x86_64\", \"version\": \"0.142.5\" }, \"remediation\": null, \"durationMs\": 0 }, \"runtime.search\": { \"id\": \"runtime.search\", \"category\": \"search\", \"status\": \"ok\", \"summary\": \"search is OK (bundled)\", \"details\": { \"search command\": \"C:\\\\Users\\\\vboxuser\\\\.codex\\\\packages\\\\standalone\\\\releases\\\\0.142.5-x86_64-pc-windows-msvc\\\\codex-path\\\\rg.exe\", \"search command readiness\": \"file exists\", \"search provider\": \"bundled\" }, \"remediation\": null, \"durationMs\": 0 }, \"sandbox.helpers\": { \"id\": \"sandbox.helpers\", \"category\": \"sandbox\", \"status\": \"ok\", \"summary\": \"sandbox configuration is readable\", \"details\": { \"approval policy\": \"OnRequest\", \"codex-linux-sandbox helper\": \"none\", \"execve wrapper helper\": \"none\", \"filesystem sandbox\": \"restricted\", \"network sandbox\": \"restricted\" }, \"remediation\": null, \"durationMs\": 0 }, \"state.paths\": { \"id\": \"state.paths\", \"category\": \"state\", \"status\": \"ok\", \"summary\": \"state paths and databases are inspectable\", \"details\": { \"CODEX_HOME\": \"C:\\\\Users\\\\vboxuser\\\\.codex (dir)\", \"active rollout files\": \"0 files, 0 total bytes, 0 average bytes\", \"archived rollout files\": \"0 files, 0 total bytes, 0 average bytes\", \"goals DB\": \"C:\\\\Users\\\\vboxuser\\\\.codex\\\\goals_1.sqlite (file)\", \"goals DB integrity\": \"ok\", \"log DB\": \"C:\\\\Users\\\\vboxuser\\\\.codex\\\\logs_2.sqlite (file)\", \"log DB integrity\": \"ok\", \"log dir\": \"C:\\\\Users\\\\vboxuser\\\\.codex\\\\log (missing)\", \"memories DB\": \"C:\\\\Users\\\\vboxuser\\\\.codex\\\\memories_1.sqlite (file)\", \"memories DB integrity\": \"ok\", \"sqlite home\": \"C:\\\\Users\\\\vboxuser\\\\.codex (dir)\", \"standalone release cache\": \"1 entries in C:\\\\Users\\\\vboxuser\\\\.codex\\\\packages\\\\standalone\\\\releases\", \"state DB\": \"C:\\\\Users\\\\vboxuser\\\\.codex\\\\state_5.sqlite (file)\", \"state DB integrity\": \"ok\" }, \"remediation\": null, \"durationMs\": 102 }, \"state.rollout_db_parity\": { \"id\": \"state.rollout_db_parity\", \"category\": \"threads\", \"status\": \"ok\", \"summary\": \"rollout files and state DB thread inventory agree\", \"details\": { \"default model provider\": \"openai\", \"rollout DB active files\": \"0\", \"rollout DB active rows\": \"0\", \"rollout DB archive mismatches\": \"0\", \"rollout DB archived files\": \"0\", \"rollout DB archived rows\": \"0\", \"rollout DB duplicate DB paths\": \"0\", \"rollout DB duplicate rollout thread ids\": \"0\", \"rollout DB malformed file names\": \"0\", \"rollout DB missing active rows\": \"0\", \"rollout DB missing archived rows\": \"0\", \"rollout DB model providers\": \"none\", \"rollout DB rows\": \"0\", \"rollout DB scan cap reached\": \"false\", \"rollout DB scan errors\": \"0\", \"rollout DB sources\": \"none\", \"rollout DB stale rows\": \"0\" }, \"remediation\": null, \"durationMs\": 8 }, \"system.environment\": { \"id\": \"system.environment\", \"category\": \"system\", \"status\": \"ok\", \"summary\": \"OS language en-US\", \"details\": { \"EDITOR\": \"not set\", \"VISUAL\": \"not set\", \"os\": \"Windows 10.0.28000 (Windows 11 Professional) [64-bit]\", \"os language\": \"en-US\", \"os type\": \"Windows\", \"os version\": \"10.0.28000\" }, \"remediation\": null, \"durationMs\": 0 }, \"terminal.env\": { \"id\": \"terminal.env\", \"category\": \"terminal\", \"status\": \"ok\", \"summary\": \"terminal metadata was detected\", \"details\": { \"WT_SESSION\": \"present\", \"color output\": \"enabled\", \"console input code page\": \"437\", \"console output code page\": \"437\", \"stderr console mode\": \"0x00000007 (VT processing: true)\", \"stderr is terminal\": \"true\", \"stdin is terminal\": \"true\", \"stdout console mode\": \"0x00000007 (VT processing: true)\", \"stdout is terminal\": \"true\", \"terminal\": \"Windows Terminal\", \"terminal size\": \"120x30\" }, \"remediation\": null, \"durationMs\": 2 }, \"terminal.title\": { \"id\": \"terminal.title\", \"category\": \"title\", \"status\": \"ok\", \"summary\": \"terminal title default\", \"details\": { \"terminal title activity\": \"true\", \"terminal title items\": \"activity, project-name\", \"terminal title project source\": \"cwd\", \"terminal title project value\": \"vboxuser\", \"terminal title source\": \"default\" }, \"remediation\": null, \"durationMs\": 0 }, \"updates.status\": { \"id\": \"updates.status\", \"category\": \"updates\", \"status\": \"ok\", \"summary\": \"update configuration is locally consistent\", \"details\": { \"cached latest version\": \"0.142.5\", \"check for update on startup\": \"true\", \"last checked at\": \"2026-07-01T13:59:15.103243600Z\", \"latest version\": \"0.142.5\", \"latest version status\": \"current version is not older\", \"update action\": \"standalone installer\", \"version cache\": \"C:\\\\Users\\\\vboxuser\\\\.codex\\\\version.json\" }, \"remediation\": null, \"durationMs\": 287 } } } ``` ### What issue are you seeing? During setup of Codex CLI on a clean Windows virtual machine, the elevated sandbox setup fails with the following error dialog: ``` codex-windows-sandbox-setup.exe Windows cannot find 'codex-windows-sandbox-setup.exe ``` ### What steps can reproduce the bug? On a clean virtual computer with only Windows 11 installed: 1. Open a **Terminal** window with a **PowerShell** session 2. Run `$env:CODEX_NON_INTERACTIVE=1; irm https://chatgpt.com/codex/install.ps1 | iex` ``` ==> Installing Codex CLI ==> Detected platform: Windows (x64) ==> Resolved version: 0.142.5 ==> Downloading Codex CLI ==> PATH updated for future PowerShell sessions. ==> Current PowerShell session: codex ==> Future PowerShell windows: open a new PowerShell window and run: codex Codex CLI 0.142.5 installed successfully. ``` 3. Run `codex`, sign in with ChatGPT, and trust the current directory. It asks about setting up the Codex agent sandbox: ``` Set up the Codex agent sandbox to protect your files and control network access. Learn more › 1. Set up default sandbox (requires Administrator permissions) 2. Use non-admin sandbox (higher risk if prompt injected) 3. Quit ``` 4. Choose the first option to run the elevated sandbox setup. 5. Note that you get an error dialog: \"codex-windows-sandbox-setup.exe 6. Retrying shows the same error. Instead choose **Quit** and reset the virtual machine. 7. Perform steps 1–4 again but this time launch `& \"$env:userprofile\\.codex\\packages\\standalone\\releases\\0.142.5-x86_64-pc-windows-msvc\\bin\\codex\"` instead of plain `codex`. 8. Note that now you correctly get a UAC prompt and the elevated sandbox is set up. ### What is the expected behavior? The elevated sandbox should be set up correctly when running the Codex CLI through the `codex` binary on the `PATH`. ### Additional information It seems like the issue is related to the junction at `%LOCALAPPDATA%\\Programs\\OpenAI\\Codex\\bin` (which is on the `PATH`) and to how `codex` tries to look up and/or run the `codex-windows-sandbox-setup.exe` file. Possibly a regression from 9d1bf00 that introduced the junction or 61aae56 that centralized the lookup for executables. Either way, the `helper_materialization.bundled_executable_path_for_exe` function seems to assume that the executable can be found as a sibling to the current executable or inside a `codex-resources` directory next to the current executable or its `bin` parent. This is not true when the path to `codex.exe` is `%LOCALAPPDATA%\\Programs\\OpenAI\\Codex\\bin\\codex.exe`. A possible fix would be make the junction point to the whole package instead of just `bin`, either making `Codex` the junction (to keep the path the same) or creating a new `package` junction instead of `bin` and put `...\\package\\bin` on the `PATH` instead.", "url": "https://github.com/openai/codex/issues/30829", "createdAt": "2026-07-01T14:05:22Z", "updatedAt": "2026-08-13T06:22:45Z", "timestamp": "2026-08-13T06:22:45Z", "metrics": { "reactions": 0, "comments": 9 }, "labels": [ "bug", "windows-os", "sandbox", "CLI" ], "author": "msternermxy", "state": "open", "assignees": [] }, { "id": "github:openai/codex:issue:30862", "source": "github", "group": "coding-agent-infrastructure", "project": "openai/codex", "kind": "issue", "title": "Dictation with codex on Android flakes out regularly", "text": "### What version of the Codex App are you using (From “About Codex” dialog)? Version 26.623.61825 • Released Jun 28, 2026 ### What subscription do you have? pro ### What platform is your computer? Microsoft Windows NT 10.0.26200.0 x64 ### What issue are you seeing? #### Dictation in ChatGPT Android : 👍 Dictation in ChatGPT on Android is rock solid. I've used it for many months and it has always worked great. I've dictated extremely long messages and it always handles them great. If there's ever an app glitch or other issue, the dictation feature always recovers gracefully. The resulting dictation text is always shown even if there's an issue so that I can copy the text and maybe restart the app if needed. #### Dictation in codex on ChatGPT on Android... The dictation with codex through ChatGPT on Android is another story. When it works, yes, it works great. But a few times a day it glitches out. ##### Examples - After submitting the dictation, the input widget disappears - During dictation, it will spontaneously stop listening and revert to the blank input widget ##### Suggestion - If there's ever an issue with the connection to the remote codex, always preserver the resulting dictation text to allow the user to send later. ### What steps can reproduce the bug? Use dictation a bunch of times in codex on ChatGPT Android. Eventually the issue happens. ### What is the expected behavior? Make dictation with codex on Android as stable and reliable as dictation with ChatGPT Android. ### Additional information _No response_", "url": "https://github.com/openai/codex/issues/30862", "createdAt": "2026-07-01T19:37:10Z", "updatedAt": "2026-08-13T05:06:35Z", "timestamp": "2026-08-13T05:06:35Z", "metrics": { "reactions": 0, "comments": 3 }, "labels": [ "bug", "codex-web", "app" ], "author": "dharmatech", "state": "open", "assignees": [] }, { "id": "github:openai/codex:issue:31018", "source": "github", "group": "coding-agent-infrastructure", "project": "openai/codex", "kind": "issue", "title": "macOS Codex desktop app: window controls are overlapped at 100% zoom", "text": "### What version of the Codex App are you using (From “About Codex” dialog)? 26.623.101652 ### What subscription do you have? ChatGPT Plus ### What platform is your computer? Darwin 22.6.0 x86_64 i386 ### What issue are you seeing? macOS Codex desktop app: at 100% zoom, the top-left window controls are overlapped by the app header/sidebar controls. At 90% zoom it no longer happens. Steps to reproduce: 1. Open Codex desktop app on macOS. 2. Set zoom to 100%. 3. Look at the top-left window controls. Expected: The macOS window controls should remain visible and unobstructed. Actual: The window controls are partially overlapped by the Codex header/sidebar controls. Workaround: Set zoom to 90%. \"Image\" ### What steps can reproduce the bug? 1. Open the Codex desktop app on macOS. 2. Set the app zoom to 100%. 3. Look at the top-left corner of the app window. Result: The macOS window controls are overlapped by the Codex header/sidebar controls. Expected: The macOS window controls should remain visible and unobstructed. Additional note: If the app zoom is changed to 90%, the overlap no longer happens. ### What is the expected behavior? _No response_ ### Additional information _No response_", "url": "https://github.com/openai/codex/issues/31018", "timestamp": "2026-08-12T13:47:56Z", "metrics": { "reactions": 0, "comments": 2 }, "labels": [ "bug", "app" ], "author": "mounteee", "assignees": [], "change": "new" }, { "id": "github:openai/codex:issue:31187", "source": "github", "group": "coding-agent-infrastructure", "project": "openai/codex", "kind": "issue", "title": "Support multi-account and multi-machine Codex mobile Remote Control connections", "text": "## Summary Please support first-class multi-account and multi-machine connections for Codex mobile Remote Control. Right now, Codex mobile Remote Control appears to work best when there is a single active desktop host / enrollment. In real development setups, users often have multiple ChatGPT accounts or workspaces and multiple machines, and the current model can become confusing or fragile. ## Problem Common real-world setups include: - A personal ChatGPT account plus a Business / Enterprise workspace. - Multiple desktop hosts, for example a Windows workstation, a Mac laptop, and an SSH / devbox environment. - Multiple Codex Desktop sessions or app-server owners over time. - Switching between accounts on the same desktop install. In these cases, Codex mobile Remote Control can become hard to reason about: - Mobile may show only one available host instead of multiple authorized machines. - A newer host can appear to overwrite or hide a previous host. - A stale host can remain visible as offline. - Switching accounts can leave stale enrollment state behind. - Desktop can fail enabling Remote Control with messages such as: ```text Could not enable remote control. Please ensure only one instance of Codex is running. ``` This makes it unclear which account, workspace, machine, and project the mobile app is actually connecting to. ## Expected behavior It would be useful if Codex mobile Remote Control supported a clearer multi-host / multi-account model: - Mobile lists multiple authorized Codex desktop hosts per account / workspace. - Each host has a stable identity, display name, platform, workspace/account scope, and last-seen status. - Desktop host enrollment is scoped by account, workspace, and machine, instead of being overwritten by another host. - Users can revoke, forget, or reset stale hosts from both desktop and mobile. - Switching accounts on the same desktop install cleanly switches or re-enrolls the host without leaking stale state from the previous account. - The UI clearly shows which host, account/workspace, project, and execution environment will receive the remote session. - If only one active instance is allowed, the app should identify which instance is blocking enrollment and offer a safe cleanup path. ## Why this matters Codex is often used across several development contexts, not just one laptop: - Personal projects vs. company workspace. - Windows desktop plus Mac laptop. - Local projects plus SSH / remote Linux projects. - Long-running tasks that users want to monitor or continue from mobile. For these users, mobile Remote Control becomes much more useful if it can explicitly manage multiple machines and multiple account/workspace enrollments. ## Related issues This request is related to several existing reports around host identity, stale enrollments, account switching, and mobile Remote Control behavior: - #22950 - #23339 - #23977 - #23082 Those issues each cover important individual cases. This issue is a broader product request for a clear, supported multi-account / multi-machine connection model. ## Environment Observed while using Codex Desktop on Windows with the mobile Remote Control flow. The exact machine/account identifiers are intentionally omitted.", "url": "https://github.com/openai/codex/issues/31187", "createdAt": "2026-07-05T18:17:31Z", "updatedAt": "2026-08-13T08:30:34Z", "timestamp": "2026-08-13T08:30:34Z", "metrics": { "reactions": 1, "comments": 2 }, "labels": [ "enhancement", "iOS", "app", "remote" ], "author": "VectorPeak", "state": "open", "assignees": [] }, { "id": "github:openai/codex:issue:31265", "source": "github", "group": "coding-agent-infrastructure", "project": "openai/codex", "kind": "issue", "title": "deny-read permission profile silently ineffective on native Windows (ACL state empty) — 0.142.5", "text": "## Summary On native Windows, a permission profile with a valid `deny` filesystem rule does not apply read denial. `write` denial works; `read` denial does not. Sandboxed commands can still read files that a `deny` rule should block (e.g. ~/.codex/config.toml). ## Environment - codex-cli 0.142.5 (latest stable) - Windows 11 Home, build 26200 - Native Windows sandbox, `[windows] sandbox = \"elevated\"` (elevated backend set up) ## Config (corrected to documented syntax) ```toml default_permissions = \"review-egress\" [permissions.review-egress.filesystem] \"~/.ssh\" = \"deny\" [permissions.review-egress.filesystem.\":workspace_roots\"] \".\" = \"read\" ``` ## Steps to reproduce 1. Apply the config above with the elevated Windows sandbox backend. 2. Run a sandboxed command that reads an absolute path under a `deny` rule. 3. Observed: the file is read successfully; `deny_read_acl_state.json` remains empty (`{\"principals\": {}}`). 4. Expected: read is blocked by policy (parity with write-deny, and with macOS/Linux). ## Notes - write-deny behaves correctly; only read-deny is ineffective. - Non-elevated returns an \"elevated backend required\" error (i.e. the rule is now recognized, unlike undocumented keys which were silently ignored). - Sandbox log shows \"read-acl-only mode: applying read ACLs\" completing in ~1ms with no deny ACEs applied. - Possibly related: #28566, #30758. ## Impact Any workflow relying on read-deny for secret isolation on native Windows is silently unprotected, with no error surfaced when the elevated backend is present.", "url": "https://github.com/openai/codex/issues/31265", "createdAt": "2026-07-06T17:11:41Z", "updatedAt": "2026-08-13T17:35:15Z", "timestamp": "2026-08-13T17:35:15Z", "metrics": { "reactions": 0, "comments": 2 }, "labels": [ "bug", "windows-os", "sandbox", "CLI" ], "author": "yoshitakafumoto-xyn", "state": "open", "assignees": [] }, { "id": "github:openai/codex:issue:31499", "source": "github", "group": "coding-agent-infrastructure", "project": "openai/codex", "kind": "issue", "title": "Windows Desktop app-server repeatedly spawns duplicate MCP stdio process pools (183 node.exe / 13GB private memory)", "text": "## Summary Codex Desktop on Windows repeatedly starts duplicate stdio MCP process pools under `codex.exe app-server --analytics-default-enabled`. The duplicate `cmd -> npx/npx.cmd -> node.exe` trees are not consistently reaped, causing large memory growth. This appears related to: - #28361 - #30408 - #30753 - #29079 I am filing a separate report because this reproduces on the current Windows Desktop app installed on my machine, and the process count/memory growth is severe enough to affect normal use. ## Environment - OS: Microsoft Windows 11 Home Chinese, 64-bit - OS version/build: 10.0.22621 / build 22621 - Codex Desktop package: `OpenAI.Codex_26.527.3686.0_x64__2p2nqsd0c76g0` - Codex Desktop version: `26.527.3686.0` - `~/.codex/version.json`: `latest_version` is `0.142.5` - App server command observed: - `codex.exe app-server --analytics-default-enabled` Global MCP servers configured in `~/.codex/config.toml`: - `reactbits`: `npx -y reactbits-dev-mcp-server` - `tavily`: `npx.cmd -y tavily-mcp` - `chrome-devtools`: `npx chrome-devtools-mcp@latest` - `shadcn`: `npx.cmd -y shadcn@latest mcp` - `figma`: HTTP MCP - `node_repl`: bundled Codex node_repl No secrets are included here. ## Observed Behavior During normal Codex Desktop usage, Task Manager showed a large number of `node.exe` processes consuming substantial memory. Read-only process inspection showed: - Peak observed: `183` `node.exe` processes - Peak private memory: `13.2 GB` - Peak working set: `10.92 GB` - One old Desktop `app-server` process tree owned about `170` of the `node.exe` descendants and about `12.24 GB` private memory The duplicated processes were primarily repeated MCP stdio server trees: - `tavily-mcp` - `reactbits-dev-mcp-server` - `shadcn@latest mcp` - `chrome-devtools-mcp@latest` - `chrome-devtools-mcp` watchdog children Representative command lines: ```text \"node\" \"...\\\\npm-cache\\\\_npx\\\\...\\\\chrome-devtools-mcp\\\\build\\\\src\\\\bin\\\\chrome-devtools-mcp.js\" node.exe ...\\\\chrome-devtools-mcp\\\\build\\\\src\\\\telemetry\\\\watchdog\\\\main.js --parent-pid=... \"node\" \"...\\\\npm-cache\\\\_npx\\\\...\\\\shadcn\\\\dist\\\\index.js\" mcp \"node\" \"...\\\\npm-cache\\\\_npx\\\\...\\\\tavily-mcp\\\\build\\\\index.js\" \"node\" \"...\\\\npm-cache\\\\_npx\\\\...\\\\reactbits-dev-mcp-server\\\\dist\\\\index.js\" ``` After I only inspected the process tree, without killing any process and without changing config, the old `app-server` appears to have exited/restarted and the count dropped to: - `19` `node.exe` processes - about `1.5 GB` private memory However, shortly afterward, the count started increasing again: - `37` `node.exe` processes - `2.89 GB` private memory - `2.91 GB` working set Breakdown at that point: ```text chrome-devtools: 12 processes, 1.22 GB private shadcn: 8 processes, 0.68 GB private reactbits: 8 processes, 0.49 GB private tavily: 8 processes, 0.47 GB private codex-node: 1 process, 0.02 GB private ``` This suggests the duplicate MCP pools are still being created after the old high-memory `app-server` tree is cleaned up. ## Expected Behavior Codex Desktop should not create unbounded duplicate MCP stdio process pools. At most one active MCP process pool should exist per owning active session/thread, and MCP child processes should be reliably cleaned up when the owning session/thread/app-server lifecycle ends. ## Actual Behavior The Desktop `app-server` creates multiple full MCP stdio process pools. Those pools accumulate under the app-server and can grow to hundreds of `node.exe` processes and more than 10 GB of memory. In my case, the leak/duplication was visible without any project dev server being involved. The repeated processes came from Codex MCP startup, not from application code. ## Impact This makes Codex Desktop risky to keep open for long sessions on Windows when several stdio MCP servers are configured. Memory growth can become large enough to degrade the machine and force users to manually kill processes or restart Codex. ## Notes This looks especially close to #28361 and #30753: - #28361 describes Windows app-server/MCP children not being reaped and accumulating to hundreds. - #30753 describes Windows Desktop creating duplicate MCP pools after `RefreshMcpServers` on a hidden thread. The extra data point here is that I observed both behaviors in one session: 1. a very large old app-server tree with around 170 duplicate `node.exe` descendants; 2. automatic cleanup/restart reducing the count; 3. new duplicate MCP pools appearing again afterward.", "url": "https://github.com/openai/codex/issues/31499", "createdAt": "2026-07-07T23:25:47Z", "updatedAt": "2026-08-13T05:16:52Z", "timestamp": "2026-08-13T05:16:52Z", "metrics": { "reactions": 1, "comments": 7 }, "labels": [ "bug", "windows-os", "mcp", "app", "app-server", "performance" ], "author": "xxH7r", "state": "open", "assignees": [] }, { "id": "github:openai/codex:issue:31553", "source": "github", "group": "coding-agent-infrastructure", "project": "openai/codex", "kind": "issue", "title": "Codex VS Code extension stopped auto-including IDE context after update", "text": "### What version of the IDE extension are you using? 26.623.141536 ### What subscription do you have? Pro ### Which IDE are you using? VS Code remote/container (.vscode-server) ### What platform is your computer? Windows 11, Docker ### What issue are you seeing? Date observed: July 8, 2026 Previously working: July 7, 2026 Behavior before: prompts automatically included open file and selected text Behavior now: open file and highlighted selection are no longer referenced unless manually added ### What steps can reproduce the bug? Select text in an open file in the IDE and prompt agent \"What text have I selected?\" ### What is the expected behavior? Codex IDE extension should automatically include open files and selected text, per docs ### Additional information - Explicit commands still exist: Add to Codex Thread / Add File to Codex Thread - No documented setting found to disable automatic IDE context - Shared config had model pinned to gpt-5.4", "url": "https://github.com/openai/codex/issues/31553", "createdAt": "2026-07-08T09:26:15Z", "updatedAt": "2026-08-12T21:27:05Z", "timestamp": "2026-08-12T21:27:05Z", "metrics": { "reactions": 12, "comments": 17 }, "labels": [ "bug", "windows-os", "extension" ], "author": "ps-bobbykotzev", "state": "open", "assignees": [] }, { "id": "github:openai/codex:issue:31606", "source": "github", "group": "coding-agent-infrastructure", "project": "openai/codex", "kind": "issue", "title": "Reset failed, did not apply and 1 reset is wasted", "text": "### What version of the Codex App are you using (From “About Codex” dialog)? Version 26.623.141536 ### What subscription do you have? Pro ### What platform is your computer? Windows ### What issue are you seeing? I used one of my resets and it did not apply and my reset counter dropped from 2 to 1, I did not hit the reset button again worrying that i would loose that reset too. I value my resets because my project depends on it. Can you give the reset back please. and also fix the error because time is running outttttt. Love codex though hehe ### What steps can reproduce the bug? just hit the use reset option ### What is the expected behavior? failed reset or the reset being not applied ### Additional information The usage meter has been buggy since 12 hrs ago for me", "url": "https://github.com/openai/codex/issues/31606", "createdAt": "2026-07-08T17:02:50Z", "updatedAt": "2026-08-13T01:47:12Z", "timestamp": "2026-08-13T01:47:12Z", "metrics": { "reactions": 69, "comments": 56 }, "labels": [ "bug", "rate-limits", "app" ], "author": "otpl8855-hash", "state": "open", "assignees": [] }, { "id": "github:openai/codex:issue:31674", "source": "github", "group": "coding-agent-infrastructure", "project": "openai/codex", "kind": "issue", "title": "Drag/Drop in the File Browser Sidebar", "text": "### What variant of Codex are you using? Desktop app ### What feature would you like to see? In the file browser sidebar, make it possible to select multiple files/folders and drag them to a Finder window. Please also support this for remote sessions. ### Additional information _No response_", "url": "https://github.com/openai/codex/issues/31674", "createdAt": "2026-07-09T00:43:11Z", "updatedAt": "2026-08-13T03:04:08Z", "timestamp": "2026-08-13T03:04:08Z", "metrics": { "reactions": 0, "comments": 1 }, "labels": [ "enhancement", "app", "remote" ], "author": "jtokash", "state": "open", "assignees": [] }, { "id": "github:openai/codex:issue:31693", "source": "github", "group": "coding-agent-infrastructure", "project": "openai/codex", "kind": "issue", "title": "Codex desktop in-app browser screenshots are DPI-scaled twice and tiled on Windows", "text": "### What version of the Codex App are you using (From “About Codex” dialog)? 26.623.19656.0 Additional local browser plugin/cache version observed: `C:\\Users\\gyli\\.codex\\plugins\\cache\\openai-bundled\\browser\\26.623.141536` ### What subscription do you have? Not sure / not relevant to this screenshot backend issue. ### What platform is your computer? Microsoft Windows 11 Pro 64-bit Version: 10.0.26200 Build: 26200 ### What issue are you seeing? Codex desktop in-app browser screenshots are incorrectly scaled and can be returned as a repeated 2x2 tiled image on Windows after using the documented `viewport` capability. This affects the in-app browser screenshot API enough that screenshots cannot be trusted for visual evidence or coordinate-based automation. DOM inspection and page navigation still work; the failure appears to be in the viewport/screenshot coordinate and bitmap capture path. Possibly related to openai/codex#19429, but that issue is closed and described a wrong-region capture on macOS. This report is a current Windows repro where the screenshot output becomes oversized and visibly tiled. ### What steps can reproduce the bug? Use the Codex desktop in-app browser with a non-sensitive test page. No login or third-party site is required. ```js if (globalThis.agent?.browsers == null) { const { setupBrowserRuntime } = await import( \"C:/Users/gyli/.codex/plugins/cache/openai-bundled/browser/26.623.141536/scripts/browser-client.mjs\" ); await setupBrowserRuntime({ globals: globalThis }); } globalThis.iab = await agent.browsers.get(\"iab\"); globalThis.tab = await iab.tabs.new(); const html = `
`; await tab.goto(\"data:text/html;charset=utf-8,\" + encodeURIComponent(html)); await (await iab.capabilities.get(\"viewport\")).set({ width: 1920, height: 1080 }); const metrics = await tab.playwright.evaluate(() => ({ innerWidth: window.innerWidth, innerHeight: window.innerHeight, devicePixelRatio: window.devicePixelRatio, visualViewport: window.visualViewport && { width: window.visualViewport.width, height: window.visualViewport.height, scale: window.visualViewport.scale, }, clientWidth: document.documentElement.clientWidth, clientHeight: document.documentElement.clientHeight, scrollWidth: document.documentElement.scrollWidth, scrollHeight: document.documentElement.scrollHeight, })); const bytes = await tab.screenshot({}); ``` I also reproduced it with ordinary authenticated pages, but the data URL above is sufficient and avoids leaking private user data. ### Observed diagnostic data On this machine: | viewport action | DOM `innerWidth x innerHeight` | `devicePixelRatio` | screenshot size | notes | | -- | -- | -- | -- | -- | | `reset()` | `511 x 1041` | `0.8375` | `763 x 1519` | not a normal desktop viewport | | `set({ width:1280, height:720 })` | `1910 x 1074` | `0.6700` | `2851 x 1603` | visibly tiled | | `set({ width:1600, height:900 })` | `2388 x 1343` | `0.6700` | `3564 x 2004` | visibly tiled | | `set({ width:1920, height:1080 })` | `2865 x 1611` | `0.6700` | `4276 x 2404` | visibly tiled 2x2 | Additional checks after `set({ width:1920, height:1080 })`: | screenshot call | returned size | result | | -- | -- | -- | | `tab.screenshot({})` | `4276 x 2404` | oversized 2x2 tiled capture | | `tab.screenshot({ fullPage: true })` | `4276 x 2404` | same oversized/tiled result | | `tab.screenshot({ clip: { x:0, y:0, width:1920, height:1080 } })` | `2866 x 1612` | still in the wrong scaled/tiled coordinate system | | `tab.screenshot({ clip: { x:0, y:0, width:960, height:540 } })` | `1433 x 806` | also scaled unexpectedly | | `tab.screenshot({ clip: { x:0, y:0, width:2138, height:1202 } })` | `3191 x 1794` | also scaled unexpectedly | The returned image bytes were JPEG even when saved to a `.png` filename by the caller. The file extension is not the root cause; the bitmap content itself is already wrong. ### What is the expected behavior? The in-app browser `viewport` capability should have consistent, documented semantics: * If `viewport.set({ width:1920, height:1080 })` is in CSS pixels, the page should report `window.innerWidth === 1920` and `window.innerHeight === 1080`. * If the capability is in physical pixels or DIP, the documentation should say so and the screenshot API should still return one correctly rendered page image. * `tab.screenshot({})` should capture the visible viewport once, not as a repeated/tiled bitmap. * `tab.screenshot({ fullPage:true })` should not return the same broken viewport tile. * `tab.screenshot({ clip })` should crop in a clear coordinate system and return the requested region, not a differently scaled/tiled coordinate space. ### Additional information The ratios suggest inverse DPI scaling may be applied twice: * `2865 / 1920 ≈ 1.492` * `4276 / 2865 ≈ 1.492` * `1 / 0.6700 ≈ 1.492` So the observed behavior is approximately: ```text DOM viewport width ≈ requested width / DPR screenshot width ≈ DOM viewport width / DPR ``` This is consistent with a Windows DPI / device-independent-pixel conversion bug in the in-app browser viewport or screenshot path. `agent.browsers.list()` on the affected session reports only the Codex in-app browser backend: ```json [ { \"name\": \"Codex In-app Browser\", \"type\": \"iab\", \"capabilities\": { \"browser\": [\"visibility\", \"viewport\"], \"tab\": [\"pageAssets\"] } } ] ``` For workflows that need reliable visual screenshots, this currently forces users to avoid the in-app browser and use a real Chrome/Edge/Chromium browser capture engine instead.", "url": "https://github.com/openai/codex/issues/31693", "createdAt": "2026-07-09T02:25:23Z", "updatedAt": "2026-08-13T01:07:15Z", "timestamp": "2026-08-13T01:07:15Z", "metrics": { "reactions": 0, "comments": 2 }, "labels": [ "bug", "windows-os", "app", "browser" ], "author": "guajun", "state": "closed", "assignees": [] }, { "id": "github:openai/codex:issue:31820", "source": "github", "group": "coding-agent-infrastructure", "project": "openai/codex", "kind": "issue", "title": "Conversation becomes permanently unusable after hitting 50 image limit", "text": "### What version of the Codex App are you using (From “About Codex” dialog)? 26.623.141536 ### What subscription do you have? Interprise ### What platform is your computer? Darwin 25.5.0 arm64 arm ### What issue are you seeing? After a conversation reaches the 50-image request limit, the conversation becomes permanently unusable. Once the error > Exceeded maximum number of images (50) allowed in the request. is returned, every subsequent prompt fails with the same error, even when the prompt contains only text (for example, `hey`). I manually compacted the conversation after hitting the limit, and the conversation displayed \"Context compacted\", but subsequent text-only prompts still failed with the same error. Restarting the Codex App did not resolve the issue. The conversation could not be recovered and had to be abandoned. I've attached screenshots showing: - the initial 50-image limit error, - a text-only prompt failing with the same error, - \"Context compacted\" followed by the same error again. ### What steps can reproduce the bug? 1. Start a long-running conversation in the Codex App. 2. Upload enough screenshots/images throughout the conversation to reach the image request limit. 3. Receive the error: Exceeded maximum number of images (50) allowed in the request. 4. Send a text-only prompt (for example, `hey`). 5. Observe that the same error is returned immediately. 6. Manually compact the conversation. 7. Send another text-only prompt. 8. Observe that the same error continues to occur, even after context compaction. 9. Quit and restart the Codex App. 10. Open the same conversation and send another text-only prompt. 11. Observe that the conversation still cannot be used and returns the same error. ### What is the expected behavior? Once the image limit has been reached, the conversation should remain usable. Either: - text-only prompts should continue to work without including previous image references, or - context compaction should remove or summarize old image references so the conversation can continue. The conversation should be recoverable without creating a new chat. ### Additional information Additional observations: - The conversation displayed \"Context compacted\" after I manually compacted it, but the issue persisted. - Every subsequent prompt, including simple text-only prompts such as `hey`, immediately failed with the same \"Exceeded maximum number of images (50) allowed in the request.\" error. - Restarting the Codex App did not resolve the issue. - The issue appears to affect only the existing conversation. Creating a new conversation is the only workaround, but it requires abandoning all accumulated context from the original session. - I have attached screenshots showing the initial error, the failed text-only prompt, and the conversation after context compaction.", "url": "https://github.com/openai/codex/issues/31820", "createdAt": "2026-07-09T17:18:00Z", "updatedAt": "2026-08-13T12:54:39Z", "timestamp": "2026-08-13T12:54:39Z", "metrics": { "reactions": 0, "comments": 1 }, "labels": [ "app" ], "author": "ysemanag", "state": "open", "assignees": [] }, { "id": "github:openai/codex:issue:31894", "source": "github", "group": "coding-agent-infrastructure", "project": "openai/codex", "kind": "issue", "title": "gpt-5.6 Responses Lite turns do not expose exec/code-mode tools in codex exec", "text": "## Summary `codex exec` with `gpt-5.6-sol` can report that shell/code-mode tools are unavailable, while the same prompt works with `gpt-5.5`. The issue appears to be the Responses Lite request shape: for `use_responses_lite=true` models, Codex currently moves client tool schemas into an `input[0]` item of type `additional_tools` and omits top-level `tools`. In the live 5.6 path I tested, those `additional_tools` are not exposed as callable tools, so the model does not see the public code-mode `exec` tool. ## Environment - Codex CLI: `codex-cli 0.144.0` - OS: Ubuntu 26.04 x86_64 - Model that works: `gpt-5.5` - Model that fails: `gpt-5.6-sol` ## Reproduction This works with `gpt-5.5`: ```bash codex exec --model gpt-5.5 --json --ephemeral --skip-git-repo-check --sandbox read-only 'please run ls and tell me if it works' ``` Observed: Codex emits a command execution item and runs `/bin/bash -lc ls` successfully. This fails with `gpt-5.6-sol`: ```bash codex exec --model gpt-5.6-sol --json --ephemeral --skip-git-repo-check --sandbox read-only 'please run ls and tell me if it works' ``` Observed assistant message: ```text I can’t run `ls` because no shell execution tool is available in this session. ``` ## Request capture Using a local Responses capture provider, the `gpt-5.5` request includes top-level tools: ```json { \"model\": \"gpt-5.5\", \"tool_names\": [ \"exec_command\", \"write_stdin\", \"list_mcp_resources\", \"list_mcp_resource_templates\", \"read_mcp_resource\", \"update_plan\", \"request_user_input\", \"request_plugin_install\", \"apply_patch\", \"view_image\", \"tool_search\", \"web_search\" ] } ``` The `gpt-5.6-sol` request has no top-level tools: ```json { \"model\": \"gpt-5.6-sol\", \"tools\": null, \"parallel_tool_calls\": false } ``` But `input[0]` contains the code-mode tools as `additional_tools`: ```json { \"type\": \"additional_tools\", \"role\": \"developer\", \"tool_names\": [\"exec\", \"wait\", \"request_user_input\", \"collaboration\"] } ``` The `exec` additional tool description includes nested `tools.exec_command(...)`, but the live model does not appear to receive `exec` as callable. ## Expected behavior `gpt-5.6-sol` should be able to call the public code-mode `exec` tool, and from there call nested `tools.exec_command(...)`, so simple shell prompts work as they do with `gpt-5.5`. ## Suspected cause `codex-rs/core/src/client.rs` has a Responses Lite branch in `build_responses_request` that inserts `ResponseItem::AdditionalTools { tools, ... }` into `input`, then sends `tools: None` at the top level. If the live Responses Lite path does not promote `additional_tools` into callable tool declarations, then the model is left with no callable code-mode tools. ## Candidate fix Keep the existing `additional_tools` item for the Responses Lite input contract, but also send the same client-executed tool schemas in top-level `tools`. I have a small patch ready that: - clones the generated tool schemas into `additional_tools` - preserves `tools: Some(tools)` at the top level for Responses Lite turns - updates HTTP and websocket regression tests to assert both locations match ## Related issues These are related to the same 5.6 custom `exec`/code-mode tool path, but appear to describe crashes after an `exec` tool call is emitted rather than the model not seeing `exec` at all: - #30861 - #31475", "url": "https://github.com/openai/codex/issues/31894", "createdAt": "2026-07-09T20:45:39Z", "updatedAt": "2026-08-13T15:43:44Z", "timestamp": "2026-08-13T15:43:44Z", "metrics": { "reactions": 0, "comments": 6 }, "labels": [ "bug", "exec", "CLI", "tool-calls" ], "author": "willsmanley", "state": "open", "assignees": [] }, { "id": "github:openai/codex:issue:31905", "source": "github", "group": "coding-agent-infrastructure", "project": "openai/codex", "kind": "issue", "title": "Unable to use gpt-5.6-sol with ChatGPT Plus", "text": "### What version of Codex CLI is running? 0.144.0 ### What subscription do you have? Plus ### Which model were you using? gpt-5.6-sol ### What platform is your computer? Linux 7.1.3-arch1-1 x86_64 unknown ### What terminal emulator and version are you using (if applicable)? st ### Codex doctor report ```json { \"schemaVersion\": 1, \"generatedAt\": \"1783631946s since unix epoch\", \"overallStatus\": \"warning\", \"codexVersion\": \"0.144.0\", \"checks\": { \"app_server.status\": { \"id\": \"app_server.status\", \"category\": \"app-server\", \"status\": \"ok\", \"summary\": \"background server is not running\", \"details\": { \"control socket\": \"/home/netsolution/.dotfiles/config/codex/app-server-control/app-server-control.sock\", \"daemon state dir\": \"/home/netsolution/.dotfiles/config/codex/app-server-daemon\", \"mode\": \"ephemeral\", \"pid file\": \"/home/netsolution/.dotfiles/config/codex/app-server-daemon/app-server.pid (missing)\", \"settings\": \"/home/netsolution/.dotfiles/config/codex/app-server-daemon/settings.json (missing)\", \"status\": \"not running\", \"update-loop pid file\": \"/home/netsolution/.dotfiles/config/codex/app-server-daemon/app-server-updater.pid (missing)\" }, \"remediation\": null, \"durationMs\": 0 }, \"auth.credentials\": { \"id\": \"auth.credentials\", \"category\": \"auth\", \"status\": \"ok\", \"summary\": \"auth is configured\", \"details\": { \"auth env vars present\": \"OPENAI_API_KEY\", \"auth file\": \"/home/netsolution/.dotfiles/config/codex/auth.json\", \"auth storage mode\": \"File\", \"stored API key\": \"false\", \"stored ChatGPT tokens\": \"true\", \"stored agent identity\": \"false\", \"stored auth mode\": \"chatgpt\" }, \"remediation\": null, \"durationMs\": 0 }, \"config.load\": { \"id\": \"config.load\", \"category\": \"config\", \"status\": \"ok\", \"summary\": \"config loaded\", \"details\": { \"CODEX_HOME\": \"/home/netsolution/.dotfiles/config/codex\", \"config.toml\": \"/home/netsolution/.dotfiles/config/codex/config.toml\", \"config.toml parse\": \"ok\", \"cwd\": \"/home/netsolution/.dotfiles/config/codex\", \"enabled feature flags\": \"shell_tool, unified_exec, shell_snapshot, code_mode_host, terminal_resize_reflow, sqlite, hooks, enable_request_compression, multi_agent, apps, tool_search_always_defer_mcp_tools, tool_suggest, plugins, in_app_browser, browser_use, browser_use_full_cdp_access, browser_use_external, computer_use, remote_plugin, plugin_sharing, image_generation, resize_all_images, skill_mcp_dependency_install, mentions_v2, steer, goals, collaboration_modes, tool_call_mcp_elicitation, auth_elicitation, personality, tui_app_server, remote_compaction_v2, workspace_dependencies\", \"feature flag overrides\": \"guardian_approval=false, fast_mode=false\", \"feature flags enabled\": \"33\", \"log dir\": \"/home/netsolution/.dotfiles/config/codex/log\", \"mcp servers\": \"0\", \"model\": \"gpt-5.6-sol\", \"model provider\": \"openai\", \"sqlite home\": \"/home/netsolution/.dotfiles/config/codex\" }, \"remediation\": null, \"durationMs\": 0 }, \"git.environment\": { \"id\": \"git.environment\", \"category\": \"git\", \"status\": \"ok\", \"summary\": \"git version 2.55.0\", \"details\": { \".git entry\": \"directory\", \"PATH git #1\": \"/usr/bin/git\", \"PATH git entries\": \"1\", \"git branch\": \"main\", \"git build options\": \"git version 2.55.0; cpu: x86_64; built from commit: e9019fcafe0040228b8631c30f97ae1adb61bcdc; sizeof-long: 8; sizeof-size_t: 8; shell-path: /bin/sh; rust: enabled; feature: fsmonitor--daemon; gettext: enabled; libcurl: 8.21.0; OpenSSL: OpenSSL 3.6.3 9 Jun 2026; zlib-ng: 2.3.3; SHA-1: SHA1_DC; SHA-256: SHA256_BLK; default-ref-format: files; default-hash: sha1\", \"git exec path\": \"/usr/lib/git-core\", \"git version\": \"git version 2.55.0\", \"repo detected\": \"true\", \"repo root\": \"/home/netsolution/.dotfiles\", \"selected git\": \"/usr/bin/git\" }, \"remediation\": null, \"durationMs\": 20 }, \"installation\": { \"id\": \"installation\", \"category\": \"install\", \"status\": \"ok\", \"summary\": \"installation looks consistent\", \"details\": { \"PATH codex #1\": \"/home/netsolution/.local/share/pnpm/bin/codex\", \"current executable\": \"/home/netsolution/.local/share/pnpm/store/v11/links/@openai/codex/0.144.0-linux-x64/30990860d23ef9e480d1170916e079d2f73241982cfb045d57e9368f1e23692d/node_modules/@openai/codex/vendor/x86_64-unknown-linux-musl/bin/codex\", \"install context\": \"pnpm (package /home/netsolution/.local/share/pnpm/store/v11/links/@openai/codex/0.144.0-linux-x64/30990860d23ef9e480d1170916e079d2f73241982cfb045d57e9368f1e23692d/node_modules/@openai/codex/vendor/x86_64-unknown-linux-musl, bin /home/netsolution/.local/share/pnpm/store/v11/links/@openai/codex/0.144.0-linux-x64/30990860d23ef9e480d1170916e079d2f73241982cfb045d57e9368f1e23692d/node_modules/@openai/codex/vendor/x86_64-unknown-linux-musl/bin, resources /home/netsolution/.local/share/pnpm/store/v11/links/@openai/codex/0.144.0-linux-x64/30990860d23ef9e480d1170916e079d2f73241982cfb045d57e9368f1e23692d/node_modules/@openai/codex/vendor/x86_64-unknown-linux-musl/codex-resources, path /home/netsolution/.local/share/pnpm/store/v11/links/@openai/codex/0.144.0-linux-x64/30990860d23ef9e480d1170916e079d2f73241982cfb045d57e9368f1e23692d/node_modules/@openai/codex/vendor/x86_64-unknown-linux-musl/codex-path)\", \"managed by bun\": \"false\", \"managed by npm\": \"false\", \"managed by pnpm\": \"true\", \"managed package root\": \"/home/netsolution/.local/share/pnpm/store/v11/links/@openai/codex/0.144.0/3eef18aa061b14c55f566321c0bd58335f90b9167ebe3a0e24052598b4240ec4/node_modules/@openai/codex\" }, \"remediation\": null, \"durationMs\": 0 }, \"mcp.config\": { \"id\": \"mcp.config\", \"category\": \"mcp\", \"status\": \"ok\", \"summary\": \"no MCP servers configured\", \"details\": {}, \"remediation\": null, \"durationMs\": 0 }, \"network.env\": { \"id\": \"network.env\", \"category\": \"network\", \"status\": \"ok\", \"summary\": \"network-related environment looks readable\", \"details\": { \"proxy env vars\": \"none\" }, \"remediation\": null, \"durationMs\": 0 }, \"network.provider_reachability\": { \"id\": \"network.provider_reachability\", \"category\": \"reachability\", \"status\": \"ok\", \"summary\": \"active provider endpoints are reachable over HTTP\", \"details\": { \"openai API base URL\": \"https://api.openai.com/v1 reachable (HTTP 404)\", \"openai API route probe\": \"https://api.openai.com/v1/ route exists (HTTP 401)\", \"reachability mode\": \"API key auth\" }, \"remediation\": null, \"durationMs\": 2118 }, \"network.websocket_reachability\": { \"id\": \"network.websocket_reachability\", \"category\": \"websocket\", \"status\": \"ok\", \"summary\": \"Responses WebSocket handshake succeeded\", \"details\": { \"DNS\": \"2 IPv4, 2 IPv6, first IPv4\", \"auth mode\": \"chatgpt\", \"connect timeout\": \"15000 ms\", \"endpoint\": \"wss://chatgpt.com/backend-api/\", \"handshake result\": \"HTTP 101 Switching Protocols\", \"model provider\": \"openai\", \"models etag present\": \"true\", \"provider name\": \"OpenAI\", \"proxy env vars\": \"none\", \"reasoning header\": \"false\", \"server model present\": \"false\", \"supports websockets\": \"true\", \"wire API\": \"responses\" }, \"remediation\": null, \"durationMs\": 639 }, \"runtime.provenance\": { \"id\": \"runtime.provenance\", \"category\": \"runtime\", \"status\": \"ok\", \"summary\": \"running pnpm on linux-x86_64\", \"details\": { \"commit\": \"unknown\", \"current executable\": \"/home/netsolution/.local/share/pnpm/store/v11/links/@openai/codex/0.144.0-linux-x64/30990860d23ef9e480d1170916e079d2f73241982cfb045d57e9368f1e23692d/node_modules/@openai/codex/vendor/x86_64-unknown-linux-musl/bin/codex\", \"install method\": \"pnpm (package /home/netsolution/.local/share/pnpm/store/v11/links/@openai/codex/0.144.0-linux-x64/30990860d23ef9e480d1170916e079d2f73241982cfb045d57e9368f1e23692d/node_modules/@openai/codex/vendor/x86_64-unknown-linux-musl, bin /home/netsolution/.local/share/pnpm/store/v11/links/@openai/codex/0.144.0-linux-x64/30990860d23ef9e480d1170916e079d2f73241982cfb045d57e9368f1e23692d/node_modules/@openai/codex/vendor/x86_64-unknown-linux-musl/bin, resources /home/netsolution/.local/share/pnpm/store/v11/links/@openai/codex/0.144.0-linux-x64/30990860d23ef9e480d1170916e079d2f73241982cfb045d57e9368f1e23692d/node_modules/@openai/codex/vendor/x86_64-unknown-linux-musl/codex-resources, path /home/netsolution/.local/share/pnpm/store/v11/links/@openai/codex/0.144.0-linux-x64/30990860d23ef9e480d1170916e079d2f73241982cfb045d57e9368f1e23692d/node_modules/@openai/codex/vendor/x86_64-unknown-linux-musl/codex-path)\", \"platform\": \"linux-x86_64\", \"version\": \"0.144.0\" }, \"remediation\": null, \"durationMs\": 0 }, \"runtime.search\": { \"id\": \"runtime.search\", \"category\": \"search\", \"status\": \"ok\", \"summary\": \"search is OK (bundled)\", \"details\": { \"search command\": \"/home/netsolution/.local/share/pnpm/store/v11/links/@openai/codex/0.144.0-linux-x64/30990860d23ef9e480d1170916e079d2f73241982cfb045d57e9368f1e23692d/node_modules/@openai/codex/vendor/x86_64-unknown-linux-musl/codex-path/rg\", \"search command readiness\": \"file exists\", \"search provider\": \"bundled\" }, \"remediation\": null, \"durationMs\": 0 }, \"sandbox.helpers\": { \"id\": \"sandbox.helpers\", \"category\": \"sandbox\", \"status\": \"ok\", \"summary\": \"sandbox configuration is readable\", \"details\": { \"approval policy\": \"OnRequest\", \"codex-linux-sandbox helper\": \"/home/netsolution/.dotfiles/config/codex/tmp/arg0/codex-arg0gs59Hx/codex-linux-sandbox\", \"execve wrapper helper\": \"/home/netsolution/.dotfiles/config/codex/tmp/arg0/codex-arg0gs59Hx/codex-execve-wrapper\", \"filesystem sandbox\": \"restricted\", \"network sandbox\": \"restricted\" }, \"remediation\": null, \"durationMs\": 0 }, \"state.paths\": { \"id\": \"state.paths\", \"category\": \"state\", \"status\": \"ok\", \"summary\": \"state paths and databases are inspectable\", \"details\": { \"CODEX_HOME\": \"/home/netsolution/.dotfiles/config/codex (dir)\", \"active rollout files\": \"703 files, 292867915 total bytes, 416597 average bytes\", \"archived rollout files\": \"0 files, 0 total bytes, 0 average bytes\", \"goals DB\": \"/home/netsolution/.dotfiles/config/codex/goals_1.sqlite (file)\", \"goals DB integrity\": \"ok\", \"log DB\": \"/home/netsolution/.dotfiles/config/codex/logs_2.sqlite (file)\", \"log DB integrity\": \"ok\", \"log dir\": \"/home/netsolution/.dotfiles/config/codex/log (dir)\", \"memories DB\": \"/home/netsolution/.dotfiles/config/codex/memories_1.sqlite (file)\", \"memories DB integrity\": \"ok\", \"sqlite home\": \"/home/netsolution/.dotfiles/config/codex (dir)\", \"state DB\": \"/home/netsolution/.dotfiles/config/codex/state_5.sqlite (file)\", \"state DB integrity\": \"ok\" }, \"remediation\": null, \"durationMs\": 273 }, \"state.rollout_db_parity\": { \"id\": \"state.rollout_db_parity\", \"category\": \"threads\", \"status\": \"warning\", \"summary\": \"rollout files and state DB thread inventory differ\", \"details\": { \"default model provider\": \"openai\", \"rollout DB active files\": \"510\", \"rollout DB active rows\": \"418\", \"rollout DB archive mismatches\": \"0\", \"rollout DB archived files\": \"0\", \"rollout DB archived rows\": \"0\", \"rollout DB duplicate DB paths\": \"0\", \"rollout DB duplicate rollout thread ids\": \"0\", \"rollout DB malformed file names\": \"0\", \"rollout DB missing active rows\": \"92\", \"rollout DB missing active sample\": [ \"/home/netsolution/.dotfiles/config/codex/sessions/2025/10/30/rollout-2025-10-30T18-51-09-019a3675-a040-7922-8c77-7006d654f20e.jsonl\", \"/home/netsolution/.dotfiles/config/codex/sessions/2025/10/30/rollout-2025-10-30T18-51-39-019a3676-1573-7c83-a20c-d9f89693bd83.jsonl\", \"/home/netsolution/.dotfiles/config/codex/sessions/2025/10/29/rollout-2025-10-29T22-05-53-019a3201-8d09-7df1-8ec1-2cb025d6f663.jsonl\", \"/home/netsolution/.dotfiles/config/codex/sessions/2025/10/28/rollout-2025-10-28T22-14-21-019a2ce2-ef9e-7870-a40b-2fb3fff70c41.jsonl\", \"/home/netsolution/.dotfiles/config/codex/sessions/2025/10/28/rollout-2025-10-28T22-31-46-019a2cf2-e190-7b12-959b-fc1e438a9457.jsonl\" ], \"rollout DB missing archived rows\": \"0\", \"rollout DB model providers\": \"openai=388, =26, duck=4\", \"rollout DB rows\": \"418\", \"rollout DB scan cap reached\": \"false\", \"rollout DB scan error sample\": [ \"/home/netsolution/.dotfiles/config/codex/sessions/2025/09/10/rollout-2025-09-10T15-21-52-8837a9d6-f9a5-45f8-80b1-2ccd35b71020.jsonl (no parseable rollout items)\", \"/home/netsolution/.dotfiles/config/codex/sessions/2025/09/08/rollout-2025-09-08T12-49-13-b3822f4e-7cc5-47ff-9e87-e9bb3e04b7f8.jsonl (no parseable rollout items)\", \"/home/netsolution/.dotfiles/config/codex/sessions/2025/09/07/rollout-2025-09-07T13-34-37-c18a1671-8ad4-4411-bbd3-a7d8ebf4663d.jsonl (no parseable rollout items)\", \"/home/netsolution/.dotfiles/config/codex/sessions/2025/09/07/rollout-2025-09-07T15-23-28-fca5ee4d-446b-4e7c-aa69-9acbd097262f.jsonl (no parseable rollout items)\", \"/home/netsolution/.dotfiles/config/codex/sessions/2025/09/07/rollout-2025-09-07T19-46-15-844a307f-7975-4cf4-9df7-726f1e4169a3.jsonl (no parseable rollout items)\" ], \"rollout DB scan errors\": \"193\", \"rollout DB sources\": \"cli=413, vscode=4, exec=1\", \"rollout DB stale rows\": \"0\" }, \"issues\": [ { \"severity\": \"warning\", \"cause\": \"rollout files are missing from the state DB\", \"measured\": \"92 active, 0 archived\", \"expected\": \"every rollout file has a matching threads row\", \"remedy\": null, \"fields\": [] }, { \"severity\": \"warning\", \"cause\": \"rollout scan was incomplete or found bad files\", \"measured\": \"193 scan errors, 0 malformed names, scan cap reached: false\", \"expected\": \"rollout directories are fully scannable\", \"remedy\": \"Check file permissions and unexpected files under CODEX_HOME sessions.\", \"fields\": [] } ], \"remediation\": null, \"durationMs\": 2840 }, \"system.environment\": { \"id\": \"system.environment\", \"category\": \"system\", \"status\": \"ok\", \"summary\": \"OS language en-GB\", \"details\": { \"EDITOR\": \"set\", \"LANG\": \"en_GB.UTF-8\", \"VISUAL\": \"not set\", \"os\": \"Arch Linux [64-bit]\", \"os language\": \"en-GB\", \"os type\": \"Arch Linux\", \"os version\": \"Unknown\" }, \"remediation\": null, \"durationMs\": 0 }, \"terminal.env\": { \"id\": \"terminal.env\", \"category\": \"terminal\", \"status\": \"ok\", \"summary\": \"terminal metadata was detected\", \"details\": { \"COLORTERM\": \"truecolor\", \"DISPLAY\": \"present\", \"TERM\": \"st-256color\", \"color output\": \"disabled (stdout is not a terminal)\", \"effective locale\": \"en_GB.UTF-8\", \"multiplexer\": \"tmux 3.7b\", \"stderr is terminal\": \"true\", \"stdin is terminal\": \"true\", \"stdout is terminal\": \"false\", \"terminal\": \"unknown\", \"terminal size\": \"169x28\", \"tmux allow-passthrough\": \"all\", \"tmux client termname\": \"st-256color\", \"tmux extended-keys\": \"off\", \"tmux focus-events\": \"off\", \"tmux set-clipboard\": \"external\", \"tmux xterm-keys\": \"on\" }, \"remediation\": null, \"durationMs\": 14 }, \"terminal.title\": { \"id\": \"terminal.title\", \"category\": \"title\", \"status\": \"ok\", \"summary\": \"terminal title default\", \"details\": { \"terminal title activity\": \"true\", \"terminal title items\": \"activity, project-name\", \"terminal title project source\": \"git repo root\", \"terminal title project value\": \".dotfiles\", \"terminal title source\": \"default\" }, \"remediation\": null, \"durationMs\": 0 }, \"updates.status\": { \"id\": \"updates.status\", \"category\": \"updates\", \"status\": \"ok\", \"summary\": \"update configuration is locally consistent\", \"details\": { \"cached latest version\": \"0.144.0\", \"check for update on startup\": \"true\", \"dismissed version\": \"0.142.3\", \"last checked at\": \"2026-07-09T19:26:27.369460588Z\", \"latest version\": \"0.144.0\", \"latest version status\": \"current version is not older\", \"update action\": \"pnpm add -g @openai/codex\", \"version cache\": \"/home/netsolution/.dotfiles/config/codex/version.json\" }, \"remediation\": null, \"durationMs\": 255 } } } ``` ### What issue are you seeing? When trying to use `gpt-5.6-sol` while authenticated with ChatGPT Plus, a 400 error response is received: ``` Model metadata for `gpt-5.6-sol` not found. Defaulting to fallback metadata; this can degrade performance and cause issues. ■ {\"type\":\"error\",\"status\":400,\"error\":{\"type\":\"invalid_request_error\",\"message\":\"The 'gpt-5.6-sol' model is not supported when using Codex with a ChatGPT account.\"}} ``` ### What steps can reproduce the bug? 1. Sign in to Codex using ChatGPT 2. Launch Codex with: `codex -m gpt-5.6-sol` 3. Send any prompt ### What is the expected behavior? A successful response from the model is received ### Additional information This only affects `sol`, both `gpt-5.6-luna` and `gpt-5.6-terra` work fine. Have tried logging out and back in, clearing `models_cache.json`, and trying a simplified config, but no luck. The model _does_ work when authenticated with an API key, however.", "url": "https://github.com/openai/codex/issues/31905", "createdAt": "2026-07-09T21:25:47Z", "updatedAt": "2026-08-13T12:47:42Z", "timestamp": "2026-08-13T12:47:42Z", "metrics": { "reactions": 8, "comments": 9 }, "labels": [ "bug", "auth", "CLI" ], "author": "net-solution", "state": "closed", "assignees": [] }, { "id": "github:openai/codex:issue:32036", "source": "github", "group": "coding-agent-infrastructure", "project": "openai/codex", "kind": "issue", "title": "ChatGPT Plus: Codex always attempts gpt-5.6-sol and fails", "text": "### What version of the Codex App are you using (From “About Codex” dialog)? 26.707.31428 on macOS ### What subscription do you have? Plus ### What platform is your computer? Darwin 25.5.0 arm64 arm ### What issue are you seeing? Platform: - macOS - ChatGPT Desktop 26.707.31428 - ChatGPT Plus Problem: Every Codex task fails with: \"The 'gpt-5.6-sol' model is not supported when using Codex with a ChatGPT account.\" Regular ChatGPT works normally using GPT-5.5. There is no model selector in the current ChatGPT Codex UI. Steps attempted: - Logged out/in - Reinstalled authentication - Verified latest desktop version - Verified ChatGPT works normally - Submitted desktop feedback Feedback ID: 019f4a51-94f2-7de2-859f-3b7417cbb767 ### What steps can reproduce the bug? Every Codex task fails with: \"The 'gpt-5.6-sol' model is not supported when using Codex with a ChatGPT account. ### What is the expected behavior? I expect that I should be able to select a model other than gpt-5.6-sol that would be compatible with my account and CODEX desktop app ### Additional information _No response_", "url": "https://github.com/openai/codex/issues/32036", "createdAt": "2026-07-10T05:41:09Z", "updatedAt": "2026-08-13T09:01:35Z", "timestamp": "2026-08-13T09:01:35Z", "metrics": { "reactions": 3, "comments": 1 }, "labels": [ "bug", "app" ], "author": "davidpuglia", "state": "open", "assignees": [] }, { "id": "github:openai/codex:issue:32177", "source": "github", "group": "coding-agent-infrastructure", "project": "openai/codex", "kind": "issue", "title": "Codex App: text-log attachment can trigger “Request blocked” and poison subsequent turns", "text": "### What version of the Codex App are you using (From “About Codex” dialog)? 26.707.31428 ### What subscription do you have? ChatGPT Team ### What platform is your computer? Darwin 25.5.0 arm64 arm ### What issue are you seeing? In Codex App, attaching a plain-text application log to an established thread can cause the turn to fail after approximately 3–5 seconds with only: ```text Request blocked. ``` The failure is persistent within that thread. Sending a subsequent short message without any attachment also fails with the same generic error because the rejected attachment turn remains in the conversation history. The affected turns complete without an assistant response. Local thread events show a completed task with no final assistant message. The desktop logs do not show an authentication, rate-limit, or HTTP 401/403/429 failure. This reproduced with multiple different plain-text logs. The logs contained ordinary service diagnostics, model-loading messages, token counts, and request metadata. They did not contain credentials. A control request in a new, short thread succeeds with the same account and model. ### What steps can reproduce the bug? 1. Open Codex App and use an established local-project thread with substantial completed history. 2. Confirm that a normal turn still succeeds. 3. Attach a plain-text service log. Reproduced attachment sizes ranged from approximately 42 KB / 425 lines to 115 KB / 1,094 lines. 4. Ask Codex to inspect or summarize the log. 5. Observe that the turn ends after approximately 3–5 seconds with `Request blocked.` and no assistant message. 6. Send a short follow-up without an attachment. 7. Observe that the follow-up is also blocked because the rejected attachment turn remains in the thread history. 8. Create a new thread in the same project and send a short prompt without carrying over the attachment. Observe that it succeeds. Relevant diagnostics: - Model: `gpt-5.6-sol`, medium reasoning. - Last successful turn before the attachment used 160,985 input tokens with a reported 353,400-token context window. - Account usage was below 10%; no rate-limit-reached state was reported. - Directly resuming the affected thread through the bundled CLI reproduces `ERROR: Request blocked.`, so this is not only a stale renderer banner. - Session identifiers are intentionally omitted for privacy, but can be supplied privately if maintainers provide a secure channel. ### What is the expected behavior? Codex App should do one of the following: 1. Accept the attachment when the combined request fits the supported context and request limits. 2. Proactively compact, truncate, or summarize the attachment/history before sending. 3. Reject the attachment before creating the turn and display a specific actionable error, such as an attachment-size or request-size limit. A failed attachment turn must not poison the thread. A subsequent message without the attachment should work, or the UI should provide a clear way to remove/rollback the rejected turn. ### Additional information - Reproduced after a full app restart. - Clearing GUI caches and refreshing authentication did not change the behavior. - Authentication and ordinary requests remained functional. - No screenshots or raw logs are attached because they may contain private workspace information. - No absolute local paths are included in this report.", "url": "https://github.com/openai/codex/issues/32177", "createdAt": "2026-07-10T14:25:59Z", "updatedAt": "2026-08-13T14:55:39Z", "timestamp": "2026-08-13T14:55:39Z", "metrics": { "reactions": 19, "comments": 17 }, "labels": [ "bug", "context", "app", "session" ], "author": "66Ton99", "state": "open", "assignees": [] }, { "id": "github:openai/codex:issue:32297", "source": "github", "group": "coding-agent-infrastructure", "project": "openai/codex", "kind": "issue", "title": "Built-in image generation repeatedly fails with network error after July 9 desktop update", "text": "### What version of the Codex App are you using? Current Codex Desktop build installed after the July 9, 2026 update. The exact About-dialog version was not available in this session. ### What subscription do you have? ChatGPT subscription using the normal Codex Desktop sign-in. ### What platform is your computer? macOS, Apple Silicon. ### What issue are you seeing? The built-in `image_gen` tool repeatedly fails while sending the generation request to the Codex image endpoint. The returned error is: ```text image generation failed: network error: error sending request for url (https://chatgpt.com/backend-api/codex/images/generations) ``` Ordinary text conversations and other Codex operations continue to work in the same session. This appears specific to the built-in image-generation route rather than a general loss of connectivity. Two separate image-generation attempts failed in the same way. Each request remained in a generating state for several minutes before returning the network error. ### What steps can reproduce the bug? 1. Open Codex Desktop. 2. Start a normal local task. 3. Ask Codex to use its built-in image generation tool to create a new image. 4. The request stays in the generating state for several minutes. 5. It eventually fails with the network error shown above. 6. Retry with a different, shorter prompt; the same failure occurs. ### What is the expected behavior? The built-in image generation request should complete and display or save the generated image. If the image service is unavailable, the app should fail promptly with a useful status instead of waiting several minutes. ### Additional information - Reproduced twice on July 11, 2026. - The prompts contained no reference images or unusual input. - Related recent reports after the same update window may include #32153, #32208, and #32038, although their visible failure modes are not identical. - No full diagnostic bundle is attached because it may contain unrelated local environment information. Additional narrowly scoped diagnostics can be provided if maintainers specify exactly which fields are needed.", "url": "https://github.com/openai/codex/issues/32297", "createdAt": "2026-07-11T00:35:21Z", "updatedAt": "2026-08-13T07:42:38Z", "timestamp": "2026-08-13T07:42:38Z", "metrics": { "reactions": 8, "comments": 23 }, "labels": [ "bug", "app", "connectivity", "imagen" ], "author": "woodenxyz", "state": "open", "assignees": [] }, { "id": "github:openai/codex:issue:32309", "source": "github", "group": "coding-agent-infrastructure", "project": "openai/codex", "kind": "issue", "title": "high-frequency code-mode polling, amplified by a very large resumed context", "text": "_After consiming unusual huge tokens usage with a Codex Sol 5.6 ~600mln tokens for a day vs usual 150-200mln on a same code base and same sessions from Codex 5.5 i passed a logs to a Codes to understand if this is not my own WSL bug fix (https://github.com/openai/codex/issues/16690) that force me to build a codex-cli every wheek with latest upstream fixes._ And Codex 5.6 Sol xHigh found a possible culprit (maybe this is a known issue?): **During the final Medium interval:** - 43 minutes, 2 user messages - 292 model responses - 96 exec calls and 192 wait calls - All 192 waits explicitly used yield_time_ms: 1000 - 49.39M raw tokens - Only 10,828 reasoning tokens - Five-hour usage increased from 58% to 100% - Cache ratio was healthy at 98.3% The CLI documents a 10-second default (codex-rs/core/src/tools/code_mode/wait_spec.rs:13), but accepts the model’s one-second value unchanged (codex-rs/core/src/tools/code_mode/wait_handler.rs:92). There is no minimum clamp. Every poll causes another model response with approximately 170K–240K input tokens. **Other Findings** The parent rollout now totals 1.153B raw tokens, with 95.4% cached. Most historical usage was GPT-5.5 xhigh (967M), but Sol added 268M on July 10 alone. Secondary contributors: - One guardian auto-review used 60,882 additional raw tokens. approvals_reviewer = \"auto_review\" is enabled. - Historical view_image outputs occupy 132.6 MB, including 48 outputs over 1 MB. - Multi-agent is enabled but no actual spawn_agent activity appears. - There were no code-mode-host spawn failures in the parent thread. - No goals or automatic goal continuations were detected. On time of investigation upstream still don't have a fixes.", "url": "https://github.com/openai/codex/issues/32309", "timestamp": "2026-08-12T12:39:39Z", "metrics": { "reactions": 4, "comments": 8 }, "labels": [ "bug", "rate-limits", "CLI", "context", "tool-calls", "performance" ], "author": "ssh4net", "assignees": [], "change": "new" }, { "id": "github:openai/codex:issue:32464", "source": "github", "group": "coding-agent-infrastructure", "project": "openai/codex", "kind": "issue", "title": "[Windows] `codex app` falsely reports Desktop missing when StartApps entry is named ChatGPT", "text": "### What version of Codex CLI is running? `codex-cli 0.144.0-alpha.4` ### What version of Codex Desktop is installed? `OpenAI.Codex 26.707.3748.0` from the Microsoft Store / AppX package. ### Platform - Microsoft Windows 11 Pro - Version `10.0.26200`, build `26200` - 64-bit ### What issue are you seeing? On Windows, `codex app ` reports that Codex Desktop is not installed and opens the installer even though the current `OpenAI.Codex` AppX package is installed, healthy, running, and its `codex://` protocol is registered. Observed output: ```text Codex Desktop not found; opening Windows installer... After installing Codex Desktop, open workspace C:\\work\\repo. ``` The false negative comes from the current installation check in `codex-rs/cli/src/desktop_app/windows.rs`: ```powershell Get-StartApps -Name 'Codex' | Select-Object -First 1 -ExpandProperty AppID ``` On the affected installation, the package's Start entry is named **ChatGPT**, not **Codex**: ```powershell PS> Get-StartApps -Name 'Codex' # no output PS> Get-StartApps | Where-Object { $_.AppID -like 'OpenAI.Codex_*!App' } Name AppID ---- ----- ChatGPT OpenAI.Codex_2p2nqsd0c76g0!App ``` AppX itself is healthy: ```text Name: OpenAI.Codex Version: 26.707.3748.0 Status: Ok AppID: OpenAI.Codex_2p2nqsd0c76g0!App ``` The package manifest also registers the `codex` protocol, and protocol activation works. ### Steps to reproduce 1. Install the current Microsoft Store / AppX Codex Desktop package on a machine where its Start entry is displayed as `ChatGPT`. 2. Install or use the bundled/standalone Windows Codex CLI. 3. Run: ```powershell codex app C:\\work\\repo ``` 4. Observe that the CLI opens the installer instead of the installed Desktop app. ### Expected behavior The CLI should detect the installed `OpenAI.Codex` package independently of its localized or packaged display name, then open the existing `codex://threads/new?path=...` protocol URL. ### Suggested repair Detect the stable package/application identity rather than querying the mutable display name. For example: ```powershell Get-StartApps | Where-Object { $_.AppID -like 'OpenAI.Codex_*!App' } | Select-Object -First 1 -ExpandProperty AppID ``` Alternatively, use `Get-AppxPackage -Name OpenAI.Codex` and rely on protocol activation for the final launch check. A focused regression test should cover this case: - display name is `ChatGPT` - AppID is `OpenAI.Codex_...!App` - installation check succeeds - launcher uses the registered `codex://` protocol ### Additional evidence The executable used from LocalAppData is byte-for-byte identical to the active AppX bundled `codex.exe`; there is no stale npm Codex installation. Direct execution from `C:\\Program Files\\WindowsApps` is denied by normal package ACLs and should not be used as a workaround. Issue #28667 is related but distinct: it concerns the TUI `/app` path directly executing a packaged WindowsApps executable. This report concerns the `codex app ` preflight returning a false **not installed** result because it searches by display name.", "url": "https://github.com/openai/codex/issues/32464", "createdAt": "2026-07-11T18:33:24Z", "updatedAt": "2026-08-13T06:22:49Z", "timestamp": "2026-08-13T06:22:49Z", "metrics": { "reactions": 1, "comments": 3 }, "labels": [ "bug", "windows-os", "CLI" ], "author": "refusedzero", "state": "open", "assignees": [] }, { "id": "github:openai/codex:issue:32492", "source": "github", "group": "coding-agent-infrastructure", "project": "openai/codex", "kind": "issue", "title": "Windows app stuck on \"Finish Windows setup\" — sandbox setup never triggers a real UAC prompt, \"Retry\" fails instantly", "text": "### What version of the Codex App are you using (From “About Codex” dialog)? Unknown — the app is blocked on the \"Finish Windows setup\" screen and I cannot reach the About dialog. ### What subscription do you have? Plus ### What platform is your computer? \"$([Environment]::OSVersion | ForEach-Object VersionString) $(if ([Environment]::Is64BitOperatingSystem) { \"x64\" } else { \"x86\" })\" ### What issue are you seeing? On first launch the Windows app is stuck on the \"Finish Windows setup\" screen (\"ChatGPT necesita un permiso por única vez para funcionar en tu computadora\"). It always shows \"La instalación de Windows no se completó\", and clicking \"Reintentar la configuración de Windows\" fails instantly. No real Windows UAC prompt ever appears when clicking Retry — the UAC dialog shown on that screen is only an illustration, and no actual elevation request is triggered. The setup gate blocks before the app is usable at all. ### What steps can reproduce the bug? 1. Install the ChatGPT/Codex desktop app from the Microsoft Store on Windows 11 Pro. 2. Launch the app. 3. It shows \"Finish Windows setup\" requesting a one-time permission. 4. Click \"Reintentar la configuración de Windows\" — it fails immediately with \"La instalación de Windows no se completó\". No real UAC prompt appears. Already verified/attempted, none resolves it: - CPU virtualization: enabled (confirmed in Task Manager) - VirtualMachinePlatform and Containers-DisposableClientVM features: both enabled, rebooted - Local Administrator account; \"Run as administrator\" → same error - UAC at default level; AppInfo service running - Clean reinstall from Microsoft Store → same error - Reset %USERPROFILE%\\.codex → same error - \"Continuar con acceso limitado\" also fails - Added [windows] sandbox = \"wsl\" to config.toml → no effect (setup gate blocks before it's read) Workaround: Codex CLI inside WSL2 works fine, which points to the native Windows sandbox setup step being the broken component. Looks related to issues #26737 and #26883. ### What is the expected behavior? The app should complete the one-time Windows setup and open normally. \"Image\" ### Additional information _No response_", "url": "https://github.com/openai/codex/issues/32492", "createdAt": "2026-07-11T23:23:37Z", "updatedAt": "2026-08-13T04:32:50Z", "timestamp": "2026-08-13T04:32:50Z", "metrics": { "reactions": 5, "comments": 10 }, "labels": [ "bug", "windows-os", "sandbox", "app" ], "author": "joseluisjl4", "state": "open", "assignees": [] }, { "id": "github:openai/codex:issue:32554", "source": "github", "group": "coding-agent-infrastructure", "project": "openai/codex", "kind": "issue", "title": "Codex Desktop: set_thread_archived hangs when an active automation archives its own task", "text": "## What version of the Codex App are you using? Codex Desktop `26.707.41301` (build `5103`). ## What subscription do you have? ChatGPT Pro. ## What platform is your computer? macOS `26.1`, arm64. ## What issue are you seeing? A standalone scheduled automation can call the official `set_thread_archived` tool on its own currently active task. When it does, the tool call remains pending indefinitely: it neither archives the task nor returns a success or structured error. This reproduced twice during the same automation run on 12 July 2026, approximately 05:01–05:03 UTC. Each attempt was bounded externally and terminated after approximately 60 seconds. During both attempts: - no `thread/archive` request appeared in the Codex Desktop logs; - no `thread/archived` notification appeared; - the tool call never completed; - the active automation turn remained blocked waiting for the tool result. This does not appear to be general archive latency or an app-server outage. Across the same local Desktop log history, 131 other successful archive operations completed with a median response time of 29 ms. OpenAI’s Codex glossary describes a scheduled run as an execution that may report findings or archive itself: https://learn.chatgpt.com/docs/glossary ## Steps to reproduce 1. Create a standalone Codex scheduled task that starts each run in a fresh task. 2. Add a terminal instruction requiring the automation to archive its current task by calling: ```text set_thread_archived({ archived: true }) ``` 3. Require the automation to wait for confirmed archive success before returning. 4. Run the automation until it reaches that terminal path while its turn is still active. 5. Observe that `set_thread_archived` remains pending indefinitely. 6. Inspect the Desktop logs and observe that no `thread/archive` request or `thread/archived` event was emitted. The issue reproduced on two consecutive calls. Retrying did not reach the app server. ## Expected behavior One of the following should happen: - If self-archival is supported, Desktop should schedule the archive for after the active turn finishes, return a defined acknowledgement, and archive the completed task. - If self-archival is unsupported while a task has an active turn, the tool should fail immediately with a structured, actionable error. The official tool call should never remain pending indefinitely. ## Actual behavior Desktop accepts the `set_thread_archived` tool call but never resolves it and never dispatches `thread/archive` to the app server. Because the active automation is waiting for the tool result, the entire run remains blocked until externally terminated. This causes otherwise successful no-action automations to be reported as blocked solely because terminal task cleanup cannot complete. ## Local diagnosis Inspection of the shipped Desktop handler shows that `set_thread_archived` resolves an omitted target task ID to the calling/source task, then awaits the archive operation before returning the tool result. The observed failure boundary is before app-server dispatch: neither failed attempt emitted `thread/archive`. Combined with the handler awaiting archive completion, this suggests a circular wait: 1. The active turn calls `set_thread_archived` on itself. 2. The tool handler waits for archival to complete. 3. Archival cannot progress through the normal lifecycle while that same turn is active, or dispatch is deferred until the turn completes. 4. The turn cannot complete because it is waiting for the tool result. This is a high-confidence diagnosis from the shipped handler behaviour and Desktop logs, not a vendor-confirmed root cause. ## Related but distinct issues - #25713: archiving the active thread reaches the backend successfully, then Desktop repeatedly tries to resume the archived thread and freezes. In this report, `thread/archive` is never dispatched. - #28080: thread-management tools intermittently lose handlers or return `No handler registered`. In this report, the tool is exposed and invoked but remains pending without returning an error. - #32257: Desktop sends `thread/archive` for a regular task with an active turn and aborts that task. In this report, the active automation explicitly requests self-archival, but the request never reaches the app server and the turn hangs instead of being aborted. ## Operational workaround Do not synchronously archive a task from its own active automation turn. Leave it unarchived, archive it manually, or archive it from a separate controller after the run has completed. ## Suggested fix Guard self-targeting archive calls while the source task has an active turn. Either: - enqueue archival as a post-turn action and return a defined acknowledgement; or - reject the call immediately with a structured error explaining that an active task cannot archive itself. In either case, add a bounded timeout so the tool cannot remain pending indefinitely. Suggested regression coverage: 1. Self-archive from an active automation turn. 2. Archive an idle separate task. 3. Archive a separate task with an active turn. 4. Confirm every path returns a defined result and never leaves the tool call pending.", "url": "https://github.com/openai/codex/issues/32554", "createdAt": "2026-07-12T10:20:32Z", "updatedAt": "2026-08-13T13:55:23Z", "timestamp": "2026-08-13T13:55:23Z", "metrics": { "reactions": 1, "comments": 1 }, "labels": [ "bug", "tool-calls", "app", "automations" ], "author": "Culpable", "state": "open", "assignees": [] }, { "id": "github:openai/codex:issue:32653", "source": "github", "group": "coding-agent-infrastructure", "project": "openai/codex", "kind": "issue", "title": "Codex Desktop crashes entire application due to missing tool call result", "text": "### What version of the Codex App are you using (From “About Codex” dialog)? 26.707.6957.0 ### What subscription do you have? pro 20x ### What platform is your computer? Windows 11 x64 ### What issue are you seeing? After today's update, Codex now crashes with the following error which stops all threads, which is highly nonideal given the relatively non-severe nature of the error. (code=3221225786, signal=null). Most recent error: {\"timestamp\":\"2026-07-12T22:28:09.945506Z\",\"level\":\"ERROR\",\"fields\":{\"message\":\"Custom tool call output is missing for call id: call_gU4LyYUSjHVTKriG83dAFWSY\"},\"target\":\"codex_core::util\"} The tool call that it was attempting to achieve was an exec tool call to run a local pytest [I had mistakenly believed it was from an ssh-mcp exec, but was wrong]. ### What steps can reproduce the bug? Attempting to open a conversation that had a failed exec tool call. ### What is the expected behavior? A failed tool call should be treated as simply that and not _crash the entire application and all threads_. ### Additional information _No response_", "url": "https://github.com/openai/codex/issues/32653", "createdAt": "2026-07-12T22:40:58Z", "updatedAt": "2026-08-13T02:37:04Z", "timestamp": "2026-08-13T02:37:04Z", "metrics": { "reactions": 0, "comments": 9 }, "labels": [ "bug", "windows-os", "mcp", "tool-calls", "app", "session" ], "author": "auridian", "state": "open", "assignees": [] }, { "id": "github:openai/codex:issue:32665", "source": "github", "group": "coding-agent-infrastructure", "project": "openai/codex", "kind": "issue", "title": "[App] Allow custom presets in the model picker power slider", "text": "### What version of the Codex App are you using? Codex App 26.707.51957 ### What platform is your computer? macOS arm64 ### What feature would you like? Allow users to define the presets shown in the Codex App's Advanced model picker / power slider. The app already persists related desktop settings in `~/.codex/config.toml`, for example: ```toml [desktop] enabled-reasoning-efforts = [\"low\", \"medium\", \"high\", \"xhigh\", \"ultra\", \"max\"] show-ultra-in-model-picker-slider = true ``` It also supports global defaults such as: ```toml model = \"gpt-5.6-sol\" model_reasoning_effort = \"high\" ``` However, these settings do not let a user choose which model + reasoning combinations appear as slider stops. The current slider uses a fixed curated sequence. I would like to configure my own ordered list, for example: ```toml [desktop] model-picker-presets = [ { model = \"gpt-5.6-terra\", reasoning_effort = \"high\", label = \"Terra High\" }, { model = \"gpt-5.6-sol\", reasoning_effort = \"high\", label = \"Sol High\" }, { model = \"gpt-5.6-sol\", reasoning_effort = \"xhigh\", label = \"Sol Extra High\" }, { model = \"gpt-5.6-sol\", reasoning_effort = \"max\", label = \"Sol Max\" }, { model = \"gpt-5.6-sol\", reasoning_effort = \"ultra\", label = \"Sol Ultra\" }, ] ``` The exact schema is only illustrative. ### Why is this useful? Different users have different recurring workflows and cost/latency preferences. A fixed slider sequence forces users to open the full picker repeatedly or accept presets they do not use. Custom presets would make the shortcut genuinely useful while preserving the existing defaults for users who do not configure anything. ### Expected behavior - Keep the existing curated presets as the default. - Allow users to override the ordered slider stops in `config.toml` or Settings. - Each preset should support at least `model` and `reasoning_effort`. - Optional labels would improve clarity. - Invalid or unavailable presets should be ignored with a visible warning rather than breaking the picker. - The selected preset should stay synchronized with the full model/reasoning controls. ### Related issue #31968 discusses the current slider's fixed sequence and its treatment of Max and Ultra, but it does not request user-defined presets.", "url": "https://github.com/openai/codex/issues/32665", "createdAt": "2026-07-13T00:53:21Z", "updatedAt": "2026-08-12T14:46:20Z", "timestamp": "2026-08-12T14:46:20Z", "metrics": { "reactions": 5, "comments": 3 }, "labels": [ "enhancement", "app", "config" ], "author": "JavierPiedra", "state": "open", "assignees": [], "change": "updated" }, { "id": "github:openai/codex:issue:32823", "source": "github", "group": "coding-agent-infrastructure", "project": "openai/codex", "kind": "issue", "title": "Missing `reasoning.mode` (for `pro` mode) setting for GPT 5.6 models", "text": "### What variant of Codex are you using? CLI ### What feature would you like to see? Currently, codex has no way of setting the `reasoning.mode` parameter to `pro`. i.e. these should work (at least for those of us using API billing): ```sh codex exec -m gpt-5.6-sol -c model_reasoning_effort=xhigh -c model_reasoning_mode=pro \"Hello world\" codex exec -m gpt-5.6-luna -c model_reasoning_effort=medium -c model_reasoning_mode=pro \"Hello world\" ``` https://developers.openai.com/api/docs/guides/reasoning#reasoning-mode Related to (but not a duplicate of, as these issues are not talking about the reasoning _**mode**_, but rather the older GPT 5.5 Pro model, which does not use `reasoning.mode`): #27077 and #28709 ### Additional information This is a pretty simple fix. (Not going to waste my time doing a PR, since I know OpenAI's current policy is to refuse external PRs.)", "url": "https://github.com/openai/codex/issues/32823", "createdAt": "2026-07-13T15:41:23Z", "updatedAt": "2026-08-13T17:52:07Z", "timestamp": "2026-08-13T17:52:07Z", "metrics": { "reactions": 3, "comments": 4 }, "labels": [ "enhancement", "exec", "CLI", "config" ], "author": "Manouchehri", "state": "open", "assignees": [], "change": "new" }, { "id": "github:openai/codex:issue:32888", "source": "github", "group": "coding-agent-infrastructure", "project": "openai/codex", "kind": "issue", "title": "Auto-compaction uses stale token usage after tool output, causing unrecoverable context overflow", "text": "### Summary In a long-running app-server turn, a large tool result can push the next sampling request beyond the model context window without triggering auto-compaction. The compaction decision uses the last server-reported token usage, which does not include the newly appended tool output. Once the request fails, small follow-up turns can remain unrecoverable because pre-turn compaction also does not account for incoming context updates and user input. ### Observed behavior From a production app-server rollout (identifiers and prompt contents omitted): - Effective model context window: **258,400 tokens** - Last server-reported input usage: **242,701 tokens** - The next `function_call_output` payload was **24,143 JSON bytes** - No `context_compacted` event occurred - The next sampling request failed with an HTTP 400 - A tiny follow-up prompt on the resumed thread failed immediately with the same error - Changing the selected model on resume did not recover the thread The rollout contained 149 successful MCP tool calls and 164 token-usage updates before the failure, so this was not a model availability or authentication problem. ### Suspected cause Current `main` computes `estimated_token_count` after sampling, but compaction is gated only by `token_status.token_limit_reached`, which is derived from server-reported usage: https://github.com/openai/codex/blob/bc8222b8d9e44377a3d7c7b7970e32e7c29ec34f/codex-rs/core/src/session/turn.rs#L315-L350 The estimate is currently only included in tracing. It is not used to decide whether the newly appended tool result makes another sampling request unsafe. Pre-turn compaction has the same blind spot for newly incoming items; the source already calls this out: https://github.com/openai/codex/blob/bc8222b8d9e44377a3d7c7b7970e32e7c29ec34f/codex-rs/core/src/session/turn.rs#L153-L157 The actual pre-turn gate checks only the persisted token status before recording incoming context/user input: https://github.com/openai/codex/blob/bc8222b8d9e44377a3d7c7b7970e32e7c29ec34f/codex-rs/core/src/session/turn.rs#L800-L822 ### Expected behavior - Before a follow-up sampling request, compaction should consider the estimated model-visible context after newly appended tool outputs. - Before the first sampling request of a resumed turn, compaction should include pending context reinjection/diffs and the new user input. - A thread near the context boundary should compact and remain resumable instead of becoming permanently stuck on 400 responses. ### Suggested regression test Use a deliberately small context/auto-compaction limit: 1. Return server token usage just below the compaction threshold. 2. Append a tool result large enough that the estimated next request exceeds the threshold/window. 3. Assert that compaction runs before the next sampling request. 4. Persist/resume the same near-limit thread with a small user input and assert that pre-turn compaction runs before sampling. ### Possible fix direction Use the estimated post-append token count in the mid-turn compaction decision (conservatively taking the maximum of server usage and the local estimate), and estimate pending incoming items in `run_pre_sampling_compact` before deciding whether to compact.", "url": "https://github.com/openai/codex/issues/32888", "createdAt": "2026-07-13T22:37:51Z", "updatedAt": "2026-08-13T01:41:56Z", "timestamp": "2026-08-13T01:41:56Z", "metrics": { "reactions": 0, "comments": 3 }, "labels": [ "bug", "context", "app-server" ], "author": "andrew-stelmach-fleet", "state": "open", "assignees": [] }, { "id": "github:openai/codex:issue:32937", "source": "github", "group": "coding-agent-infrastructure", "project": "openai/codex", "kind": "issue", "title": "Image generation (\"Codex Image 2\") fails with generic \"network request failed\" — root cause is sandbox setup failing to create/init dedicated Windows accounts (CodexSandboxOnline/Offline)", "text": "### Environment - OS: Windows 11 Pro - Codex CLI: @openai/codex 0.142.4 (also affects Desktop app, e.g. build 26.707.8168.0) - sandbox_mode = \"workspace-write\", [windows] sandbox = \"elevated\" in config.toml ### Symptom Codex Image 2 (in-app image generation) fails with a generic \"network request failed\" message, without generating any image. Restarting the Codex app as Administrator does NOT resolve it. ### Root cause found (via local log inspection) 1. `.codex/.sandbox/sandbox..log` shows repeated errors starting the day of a client update: ``` write ACE failed on : SetNamedSecurityInfoW failed: 5 write ACE failed on C:\\tmp: SetNamedSecurityInfoW failed: 5 grant read ACE failed on C:\\Program Files\\WindowsApps\\OpenAI.Codex_\\app for sandbox_group: SetNamedSecurityInfoW failed: 5 ``` (Error 5 = ERROR_ACCESS_DENIED) 2. Windows Application event log (Event ID 1509) shows the actual trigger: Codex's Windows sandbox now provisions two dedicated local accounts, `CodexSandboxOnline` and `CodexSandboxOffline`. During profile initialization for these new accounts, Windows fails to copy protected reparse-point entries from the Default profile template: ``` Windows cannot copy file \\?\\C:\\Users\\Default\\AppData\\Local\\Microsoft\\WindowsApps\\Backup to \\?\\C:\\Users\\CodexSandboxOnline\\AppData\\Local\\Microsoft\\WindowsApps\\Backup ... Access is denied. ``` (same for `MicrosoftWindows.Client.CBS_cw5n1h2txyewy`) These WindowsApps entries are TrustedInstaller-protected app-execution-alias reparse points; a newly created standard/administrator account cannot copy them without elevated system-level privileges beyond normal admin token. This appears to break sandbox account provisioning, which cascades into the ACE-grant failures above, which in turn appears to surface to the end user as a generic \"network request failed\" during image generation (the sandboxed process likely never gets to the network call). 3. Ruled out: no antivirus / Controlled Folder Access is active on this machine (Defender real-time protection service not even running), so this is not a third-party security software conflict. ### Expected behavior Either the sandbox account provisioning should tolerate/skip this WindowsApps alias copy failure gracefully, or image generation should surface the real underlying error instead of a generic network failure message. ### Repro frequency Started appearing in sandbox logs starting one specific day (client auto-update), 0 occurrences in logs from the prior ~2 weeks.", "url": "https://github.com/openai/codex/issues/32937", "createdAt": "2026-07-14T03:40:34Z", "updatedAt": "2026-08-13T08:10:40Z", "timestamp": "2026-08-13T08:10:40Z", "metrics": { "reactions": 0, "comments": 3 }, "labels": [ "bug", "windows-os", "sandbox", "app", "imagen" ], "author": "acsghsc", "state": "open", "assignees": [] }, { "id": "github:openai/codex:issue:32960", "source": "github", "group": "coding-agent-infrastructure", "project": "openai/codex", "kind": "issue", "title": "Bundled spreadsheets plugin emits invalid icon path warnings on every startup", "text": "## Summary The bundled `spreadsheets` plugin from the OpenAI Primary Runtime emits two skill-metadata warnings on every fresh Codex startup. The warnings are caused by paths in the bundled plugin, not by a user's `config.toml`. ```text WARN codex_core_skills::loader: ignoring interface.icon_small: icon path with '..' must resolve under plugin assets/ WARN codex_core_skills::loader: ignoring interface.icon_large: icon path with '..' must resolve under plugin assets/ ``` ## Environment - Codex surface: Codex Desktop - Bundled CLI: `codex-cli 0.144.2` - Platform: Windows x64 - Affected plugin: `spreadsheets@openai-primary-runtime` Account identifiers, subscription details, and local machine identifiers are intentionally omitted because they are not relevant to this local metadata-validation issue. ## Steps to reproduce 1. Install or enable the bundled `spreadsheets@openai-primary-runtime` plugin. 2. Start a fresh Codex process. 3. Inspect the startup log. 4. Observe one warning for `interface.icon_small` and one for `interface.icon_large`. No related `config.toml` setting is required. ## Root cause The plugin metadata at: ```text skills/excel-live-control/agents/openai.yaml ``` references a sibling skill's asset: ```yaml icon_small: ../spreadsheets/assets/file-spreadsheet.png icon_large: ../spreadsheets/assets/file-spreadsheet.png ``` A path containing `..` is accepted only when its resolved target remains under the plugin-level `assets/` directory. These paths instead resolve into a sibling skill directory, so the loader correctly rejects them and ignores both optional icons. ## Expected behavior Bundled plugin metadata should pass validation and load both icons without warnings. ## Verified package fix I tested the following package-only correction: 1. Copy the icon to `skills/excel-live-control/assets/file-spreadsheet.png`. 2. Change both metadata values to `./assets/file-spreadsheet.png`. 3. Revalidate and reinstall the plugin package. Results: - official plugin validation passed for both source and installed cache; - source and installed-cache file hashes matched; - two independent fresh Codex starts produced zero target warnings; - `excel-live-control` remained discoverable; - all five plugins in the same Primary Runtime snapshot passed validation. ## Optional loader diagnostic hardening The package correction is the primary fix. Separately, I prepared and tested a small loader diagnostic improvement that leaves validation behavior unchanged but adds these structured warning fields: - `plugin_id` - `skill_dir` - `raw_path` - `resolved_path` - `allowed_root` The existing invalid plugin-icon regression test was extended to assert those fields. Local verification: - `just fmt`: passed - `just test -p codex-core-skills`: 118 tests passed - `git diff --check`: passed I understand that external code contributions to this repository are invitation-only. If maintainers want the diagnostic hardening after reviewing this issue, I can provide the tested patch through the invited contribution workflow. ## Privacy note This report intentionally excludes email addresses, local usernames, absolute home/workspace paths, account and subscription identifiers, thread or run identifiers, authentication material, and unrelated log lines.", "url": "https://github.com/openai/codex/issues/32960", "createdAt": "2026-07-14T05:12:39Z", "updatedAt": "2026-08-13T02:37:02Z", "timestamp": "2026-08-13T02:37:02Z", "metrics": { "reactions": 0, "comments": 1 }, "labels": [ "bug", "windows-os", "app", "skills" ], "author": "procloudkim", "state": "open", "assignees": [] }, { "id": "github:openai/codex:issue:32983", "source": "github", "group": "coding-agent-infrastructure", "project": "openai/codex", "kind": "issue", "title": "App update leaves the previous app-server daemon running", "text": "### What version of Codex CLI is running? 0.144.4 ### What subscription do you have? Pro ### Which model were you using? gpt-5.6-sol ### What platform is your computer? Linux 6.17.0-1016-gcp x86_64 x86_64 ### What terminal emulator and version are you using (if applicable)? Ghostty & tmux ### Codex doctor report ```json ``` ### What issue are you seeing? After Codex updated from `0.144.2` to `0.144.4`, the persistent app-server daemon remained on `0.144.2`. It was not restarted or replaced as part of the update, leaving remote control unavailable. Running `codex remote-control start` only exposed the stale daemon state: ```text ~ ❯ codex remote-control start Starting app-server daemon with remote control enabled... Error: app server did not become ready on /home/my/.codex/app-server-control/app-server-control.sock Daemon used app-server: path: /home/my/.codex/packages/standalone/current/codex version: 0.144.4 Managed app-server stderr (/home/my/.codex/app-server-daemon/app-server.stderr.log): 2026-07-13T06:52:56.322812Z ERROR codex_models_manager::manager: failed to refresh available models: timeout waiting for child process to exit Caused by: 0: failed to connect to /home/my/.codex/app-server-control/app-server-control.sock 1: Connection refused (os error 111) ``` The running daemon was still: ``` .../releases/0.144.2-x86_64-unknown-linux-musl/bin/codex app-server daemon pid-update-loop ``` ### What steps can reproduce the bug? 1. Install and run Codex standalone version `0.144.2`. 2. Start remote control so the persistent daemon is running: `codex remote-control start` 3. Verify the daemon uses 0.144.2: `ps -ef | grep 'app-server daemon pid-update-loop` 4. Leave the daemon running and update Codex normally to 0.144.4. 5. Confirm codex --version reports 0.144.4. 6. Check the daemon process again. Observed: the daemon continues running from the 0.144.2 release directory and remote control becomes unavailable. Running codex remote-control start fails with a connection-refused error on app-server-control.sock. Expected: the update should restart or replace the persistent daemon so it runs 0.144.4 and remote control remains available. ### What is the expected behavior? When Codex updates, the persistent app-server daemon should survive safely or (ideally) be restarted using the new version. ### Additional information _No response_", "url": "https://github.com/openai/codex/issues/32983", "createdAt": "2026-07-14T06:37:01Z", "updatedAt": "2026-08-12T21:38:00Z", "timestamp": "2026-08-12T21:38:00Z", "metrics": { "reactions": 0, "comments": 2 }, "labels": [ "bug", "CLI", "app-server", "remote" ], "author": "galah92", "state": "open", "assignees": [] }, { "id": "github:openai/codex:issue:32993", "source": "github", "group": "coding-agent-infrastructure", "project": "openai/codex", "kind": "issue", "title": "Codex CLI: add persistent self-healing monitor workflows for long-running jobs", "text": "### What variant of Codex are you using? Codex CLI / TUI, especially on headless Linux, SSH, and remote development machines. ### What feature would you like to see? ## Summary Add a first-class, persistent **monitor workflow** to Codex CLI that can return to the same thread at a future time or when a background event occurs, inspect progress, and perform a bounded diagnose -> fix -> restart/resume -> verify loop when it detects a failure. This is more than a timer or status reminder. The goal is to let Codex safely supervise long-running development, deployment, evaluation, and ML training jobs without requiring the user to repeatedly ask for progress updates. ## Problem A typical workflow today looks like this: 1. Codex starts a long-running build, experiment, training run, deployment, or development task. 2. The user leaves the session and returns 30 minutes later. 3. Only after the user asks for status does Codex inspect the logs and discover that the job crashed, stalled, produced bad cases, or hit a bug much earlier. 4. Time was lost because the agent had no durable way to wake itself, check progress, and continue remediation. External cron jobs can inspect a process or log, but they do not naturally preserve the active Codex thread, its context, constraints, prior diagnosis, sandbox policy, and repair history. ## Example workflows Illustrative commands: ```text /monitor in 30m \"Check the training run, summarize progress, and investigate any failures.\" /monitor every 30m --until complete --name training-guard \\ \"Inspect logs and metrics. If the run is healthy, keep waiting. If it crashed, stalled, regressed, or produced bad cases, diagnose the cause, apply fixes within the approved scope, restart or resume the run, verify recovery, and continue monitoring.\" ``` The exact syntax is not important; the end-to-end behavior is. ## Desired lifecycle ```text start job -> sleep without model calls -> wake on a timer or relevant event -> inspect process, logs, metrics, tests, and artifacts -> healthy: record status and wait again -> unhealthy: diagnose -> fix -> restart/resume -> verify -> completed: stop the monitor and report the final result -> unsafe, ambiguous, or permission-blocked: ask the user ``` ## Requirements 1. **Time- and event-based wakeups** * One-shot checks such as \"in 30 minutes\". * Recurring checks such as \"every 30 minutes\". * Optional event triggers such as process exit, matching an error pattern, file changes, CI completion, metric thresholds, or stalled progress. 2. **Same-thread continuity** * Resume the same Codex thread with its existing context and constraints. * Do not start an unrelated stateless `codex exec` run for every check. 3. **No token-burning polling while idle** * Waiting should make no model calls. * Local timers or event watchers should wake the model only when a check is due or a relevant event occurs. 4. **Bounded autonomous remediation** * On a detected failure, Codex may inspect evidence, make changes within the current sandbox and explicitly approved scope, run targeted validation, and restart or resume the job. * Preserve normal approval boundaries for privileged, destructive, publishing, or otherwise high-impact actions. * Support maximum retries, time/cost budgets, and fail-closed stop conditions to prevent runaway self-repair loops. 5. **Durability and delivery safety** * Ideally persist monitor state across terminal or app-server restarts. * Do not lose completion or failure events while the thread is busy or temporarily unavailable. * Do not interrupt an active turn; queue or coalesce the wakeup for the next safe point. 6. **Inspectable control surface** * List active monitors, next wake time, latest check, health state, and last action. * Pause, resume, trigger now, edit, and stop a monitor. * Keep a bounded history of checks, detected anomalies, repairs, validation results, and termination reason. ## Why this should be an end-to-end feature Several existing issues cover important primitives: * openai/codex#8317 and openai/codex#15679 cover delayed or recurring scheduling and `/loop`. * openai/codex#29922, openai/codex#32188, and openai/codex#32221 cover event-driven monitoring and waking an idle session without polling. * openai/codex#17737 covers a monitoring-oriented TUI and warning/error visibility. Those primitives are necessary, but this request focuses on the missing user-facing workflow and lifecycle contract: **monitor -> detect -> diagnose -> remediate -> verify -> continue or stop**, with persistent same-thread context and explicit safety boundaries. If the underlying implementation is split across the scheduler, monitor, goal, and background-exec components, this issue can serve as the end-to-end CLI behavior and acceptance criteria tying them together. ### Additional information The strongest use cases are long-running training and evaluation jobs, development servers, CI or deployment monitoring, overnight test matrices, and other workflows where discovering a failure only after the user manually asks for progress wastes substantial time.", "url": "https://github.com/openai/codex/issues/32993", "createdAt": "2026-07-14T07:19:38Z", "updatedAt": "2026-08-12T20:06:35Z", "timestamp": "2026-08-12T20:06:35Z", "metrics": { "reactions": 2, "comments": 3 }, "labels": [ "enhancement", "CLI", "automations" ], "author": "DeepThinkingZhouLiu", "state": "open", "assignees": [] }, { "id": "github:openai/codex:issue:33192", "source": "github", "group": "coding-agent-infrastructure", "project": "openai/codex", "kind": "issue", "title": "[Windows 10] DWM Composition handles accumulate after Codex tasks with tool calls", "text": "## Summary On Windows 10 22H2, I can reproduce persistent growth in DWM's `Composition` handle count after Codex tasks that make terminal tool calls. A no-tool task that replied only `OK` did not show the same growth. In one controlled five-call run, the `Composition` count increased by 22 and remained elevated throughout the 30-second period after the task finished. After about four days of normal Codex use, DWM had 22,770 `Composition` handles, compared with 817 after a DWM restart. At that point, dragging an ordinary window could lag by 10 to 20 seconds. Restarting only DWM cleared the accumulated state and immediately restored smooth window movement. In a separate control, every `ChatGPT.exe` and `codex.exe` process was absent for about 5 minutes 35 seconds. No comparable new growth was observed while Codex was closed, but the handles already held by DWM did not fall. So far, they have only been cleared by restarting DWM or Windows. I cannot yet tell whether the lifetime problem begins in the Codex UI, Electron, Chromium, DirectComposition, DWM, or the graphics driver. This report documents the repeatable trigger and the resource signature. ## Environment - Windows 10 22H2, build `19045.7417`, x64 - Codex MSIX `OpenAI.Codex_26.707.9981.0_x64` - Internal app version `26.707.72221`, build `5307` - Electron `42.1.0` - Chromium/ProductVersion `150.0.7871.115` - One internal display at `2400 x 1600`, 60 Hz; no external display - Intel Iris Xe Graphics and NVIDIA GeForce RTX 3050 Ti Laptop GPU - HAGS enabled (`HwSchMode=2`) - Variable refresh optimization enabled (`VRROptimizeEnable=1`) - MPO disabled (`OverlayTestMode=5`) I have seen the same general problem across several Codex desktop updates. The version above is the one used for the controlled captures below. ## Reproduction 1. Start from a low DWM handle count after signing in to Windows or restarting DWM. 2. Open Codex and create a new task. 3. Ask it to make several separate, read-only terminal calls, for example: ```powershell Get-Date Get-Location Get-Process -Id $PID | Select-Object Id, ProcessName, HandleCount git status --short Get-ChildItem -Name | Select-Object -First 3 ``` 4. Record the count and type of DWM handles before the task, while it runs, and for at least 30 seconds after it finishes. 5. Repeat the task a few times. It is not necessary to keep Codex in the foreground. 6. For comparison, create a new task that only replies `OK` and does not call any tools. **Expected:** After a task finishes and its status UI settles, DWM `Composition` handles should return close to their previous baseline. **Actual:** Tasks with several tool calls leave a small persistent net increase. Repeating these task cycles gradually builds a much larger DWM-side handle stock. ## Controlled results | Test | Workload | Persistent DWM handle change | `Composition` change | | --- | --- | ---: | ---: | | Plain text control | New task replied only `OK`; no tools | `+5` | `-1` | | Five terminal calls | Five separate read-only calls | `+10` | `+22` | | Idle long task view | Visible and idle for about 10 minutes | `+2` | Not sampled by type | | Idle short task view | Visible and idle for about 10 minutes | `0` | Not sampled by type | | Active task | Running for about 6 minutes | `+66` | Not sampled by type | | Active task, Codex minimized | Running in the background | `+55` | Not sampled by type | | Scheduled task | Natural unattended run | `+88` | Not sampled by type | The two controlled runs used 30-second medians before and after the task. The DWM PID remained unchanged. ## DirectComposition trace I captured the five-call test with the `Microsoft-Windows-DirectComposition` and Dwm-Core ETW providers. During the server-reported task interval, DirectComposition recorded four identical 12-resource creation batches for DWM channel `61`. None of those 48 resources had a matching release before the trace ended. An identical fifth batch appeared about 2.1 seconds before the server `startedAt` timestamp, which may reflect local task initialization, but I cannot prove that from this trace. Every batch had this resource type sequence: ```text 201, 195, 195, 32, 32, 79, 87, 39, 58, 39, 58, 30 ``` The resource handles were sequential and had `openShared=false`. This capture did not include the Dwm-Core channel-attribution keywords, so I cannot map channel `61` to a specific client PID. The same batch signature also appeared occasionally outside the task interval. I therefore treat this as a correlation clue rather than proof that channel `61` belongs to Codex. The capture used Dwm-Core keyword mask `0x21`. A follow-up trace should use `0x900021` so that it also records `PROCESS_ATTRIBUTION`, `CHANNEL_OPENED_FOR_PROCESS`, `CHANNEL_CLOSED_FOR_PROCESS`, and `COMMAND_PROCESSED_ONBEHALF`. The DirectComposition mask can remain `0x5F`. DWM kept the same PID throughout the run. There was no lock-screen transition. `Video.UI` emitted no DirectComposition create or release events during the task interval, and the `ShellExperienceHost` burst began only after completion, consistent with the completion notification. ## Related report The closest existing report I found is [#16374](https://github.com/openai/codex/issues/16374), which describes progressive Windows shell freezes associated with Codex. This may be part of the same broader problem. The additional evidence here is the DWM handle type, the no-tool control, and the DirectComposition capture. ## Package note The affected package is an Electron 42 and Chromium 150 application, not WebView2. I found task-status and sidebar lifecycle code in the packaged ASAR, but the production package has no source maps, so I could not map the observed resource lifetime to a specific source module. ## Evidence retained locally The most relevant sanitized results are included above. I have also kept the complete ETL, the two run summaries, before-and-after handle type diffs, and the extracted DirectComposition batches. I have not attached the raw ETL because it contains a wider process timeline.", "url": "https://github.com/openai/codex/issues/33192", "createdAt": "2026-07-14T23:37:42Z", "updatedAt": "2026-08-13T17:16:18Z", "timestamp": "2026-08-13T17:16:18Z", "metrics": { "reactions": 7, "comments": 9 }, "labels": [ "bug", "windows-os", "app", "performance" ], "author": "J-ShuJie", "state": "open", "assignees": [] }, { "id": "github:openai/codex:issue:33263", "source": "github", "group": "coding-agent-infrastructure", "project": "openai/codex", "kind": "issue", "title": "MCP tools wrapped as \"namespace\" tool type are ignored by non-OpenAI endpoints", "text": "### What version of Codex CLI is running? `codex-cli 0.144.4` (pnpm install, linux-x64) ### What subscription do you have? N/A — using a third-party OpenAI-compatible endpoint (not an OpenAI plan). ### Which model were you using? `deepseek-v4-pro` via an OpenAI-compatible endpoint with `wire_api = \"responses\"` ### What platform is your computer? Linux 7.1.3-200.fc44.x86_64 x86_64 unknown ### What terminal emulator and version are you using (if applicable)? Ghostty (not relevant to the bug). ### Codex doctor report ```json { \"schemaVersion\": 1, \"generatedAt\": \"1784093430s since unix epoch\", \"overallStatus\": \"ok\", \"codexVersion\": \"0.144.4\", \"checks\": { \"app_server.status\": { \"id\": \"app_server.status\", \"category\": \"app-server\", \"status\": \"ok\", \"summary\": \"background server is running\", \"details\": { \"app-server version\": \"0.144.4\", \"control socket\": \"/home/johnlin/.codex/app-server-control/app-server-control.sock\", \"daemon state dir\": \"/home/johnlin/.codex/app-server-daemon\", \"mode\": \"ephemeral\", \"pid file\": \"/home/johnlin/.codex/app-server-daemon/app-server.pid (missing)\", \"settings\": \"/home/johnlin/.codex/app-server-daemon/settings.json (missing)\", \"status\": \"running\", \"update-loop pid file\": \"/home/johnlin/.codex/app-server-daemon/app-server-updater.pid (missing)\" }, \"remediation\": null, \"durationMs\": 22 }, \"auth.credentials\": { \"id\": \"auth.credentials\", \"category\": \"auth\", \"status\": \"ok\", \"summary\": \"OpenAI auth is not required for the active model provider\", \"details\": { \"auth file\": \"/home/johnlin/.codex/auth.json\", \"auth storage mode\": \"File\", \"model provider requires OpenAI auth\": \"false\" }, \"remediation\": null, \"durationMs\": 0 }, \"config.load\": { \"id\": \"config.load\", \"category\": \"config\", \"status\": \"ok\", \"summary\": \"config loaded\", \"details\": { \"CODEX_HOME\": \"/home/johnlin/.codex\", \"config.toml\": \"/home/johnlin/.codex/config.toml\", \"config.toml parse\": \"ok\", \"cwd\": \"/home/johnlin/Dev\", \"enabled feature flags\": \"shell_tool, unified_exec, shell_snapshot, code_mode_host, terminal_resize_reflow, sqlite, hooks, enable_request_compression, multi_agent, apps, tool_search_always_defer_mcp_tools, tool_suggest, plugins, in_app_browser, browser_use, browser_use_full_cdp_access, browser_use_external, computer_use, remote_plugin, plugin_sharing, image_generation, resize_all_images, skill_mcp_dependency_install, mentions_v2, steer, guardian_approval, goals, collaboration_modes, tool_call_mcp_elicitation, auth_elicitation, personality, fast_mode, tui_app_server, remote_compaction_v2, workspace_dependencies\", \"feature flag overrides\": \"none\", \"feature flags enabled\": \"35\", \"log dir\": \"/home/johnlin/.codex/log\", \"mcp servers\": \"1\", \"model\": \"deepseek-v4-pro\", \"model provider\": \"openai_https\", \"sqlite home\": \"/home/johnlin/.codex\" }, \"remediation\": null, \"durationMs\": 0 }, \"git.environment\": { \"id\": \"git.environment\", \"category\": \"git\", \"status\": \"ok\", \"summary\": \"git version 2.55.0\", \"details\": { \"PATH git #1\": \"/usr/bin/git\", \"PATH git #2\": \"/bin/git\", \"PATH git entries\": \"2\", \"git build options\": \"git version 2.55.0; cpu: x86_64; no commit associated with this build; sizeof-long: 8; sizeof-size_t: 8; shell-path: /bin/sh; rust: disabled; feature: fsmonitor--daemon; gettext: enabled; libcurl: 8.18.0; OpenSSL: OpenSSL 3.5.7 9 Jun 2026; zlib-ng: 2.3.3; SHA-1: SHA1_DC; SHA-256: SHA256_BLK; default-ref-format: files; default-hash: sha1\", \"git exec path\": \"/usr/libexec/git-core\", \"git version\": \"git version 2.55.0\", \"repo detected\": \"false\", \"selected git\": \"/usr/bin/git\" }, \"remediation\": null, \"durationMs\": 14 }, \"installation\": { \"id\": \"installation\", \"category\": \"install\", \"status\": \"ok\", \"summary\": \"installation looks consistent\", \"details\": { \"PATH codex #1\": \"/home/johnlin/.local/share/pnpm/bin/codex\", \"current executable\": \"/home/johnlin/.local/share/pnpm/store/v11/links/@openai/codex/0.144.4-linux-x64/e2f4350a54440b272fea7a52f370f55f3b7455586f2cd0233874d5f3cdd99864/node_modules/@openai/codex/vendor/x86_64-unknown-linux-musl/bin/codex\", \"install context\": \"pnpm (package /home/johnlin/.local/share/pnpm/store/v11/links/@openai/codex/0.144.4-linux-x64/e2f4350a54440b272fea7a52f370f55f3b7455586f2cd0233874d5f3cdd99864/node_modules/@openai/codex/vendor/x86_64-unknown-linux-musl, bin /home/johnlin/.local/share/pnpm/store/v11/links/@openai/codex/0.144.4-linux-x64/e2f4350a54440b272fea7a52f370f55f3b7455586f2cd0233874d5f3cdd99864/node_modules/@openai/codex/vendor/x86_64-unknown-linux-musl/bin, resources /home/johnlin/.local/share/pnpm/store/v11/links/@openai/codex/0.144.4-linux-x64/e2f4350a54440b272fea7a52f370f55f3b7455586f2cd0233874d5f3cdd99864/node_modules/@openai/codex/vendor/x86_64-unknown-linux-musl/codex-resources, path /home/johnlin/.local/share/pnpm/store/v11/links/@openai/codex/0.144.4-linux-x64/e2f4350a54440b272fea7a52f370f55f3b7455586f2cd0233874d5f3cdd99864/node_modules/@openai/codex/vendor/x86_64-unknown-linux-musl/codex-path)\", \"managed by bun\": \"false\", \"managed by npm\": \"false\", \"managed by pnpm\": \"true\", \"managed package root\": \"/home/johnlin/.local/share/pnpm/store/v11/links/@openai/codex/0.144.4/1242d2d9b5029e994a46ca69cecef51530e5ff5c0b6064d5ed75850443bdcd45/node_modules/@openai/codex\" }, \"remediation\": null, \"durationMs\": 0 }, \"mcp.config\": { \"id\": \"mcp.config\", \"category\": \"mcp\", \"status\": \"ok\", \"summary\": \"MCP configuration is locally consistent\", \"details\": { \"configured servers\": \"1\", \"disabled servers\": \"0\", \"stdio servers\": \"1\" }, \"remediation\": null, \"durationMs\": 0 }, \"network.env\": { \"id\": \"network.env\", \"category\": \"network\", \"status\": \"ok\", \"summary\": \"network-related environment looks readable\", \"details\": { \"proxy env vars\": \"none\" }, \"remediation\": null, \"durationMs\": 0 }, \"network.provider_reachability\": { \"id\": \"network.provider_reachability\", \"category\": \"reachability\", \"status\": \"ok\", \"summary\": \"active provider endpoints are reachable over HTTP\", \"details\": { \"openai_https API base URL\": \"http://:/v1 reachable (HTTP 404)\", \"openai_https API route probe\": \"http://:/v1/ route exists (HTTP 200)\", \"reachability mode\": \"provider auth\" }, \"remediation\": null, \"durationMs\": 361 }, \"network.websocket_reachability\": { \"id\": \"network.websocket_reachability\", \"category\": \"websocket\", \"status\": \"ok\", \"summary\": \"Responses WebSocket is not enabled for the active provider\", \"details\": { \"model provider\": \"openai_https\", \"provider name\": \"OpenAI\", \"proxy env vars\": \"none\", \"supports websockets\": \"false\", \"wire API\": \"responses\" }, \"remediation\": null, \"durationMs\": 0 }, \"runtime.provenance\": { \"id\": \"runtime.provenance\", \"category\": \"runtime\", \"status\": \"ok\", \"summary\": \"running pnpm on linux-x86_64\", \"details\": { \"commit\": \"unknown\", \"current executable\": \"/home/johnlin/.local/share/pnpm/store/v11/links/@openai/codex/0.144.4-linux-x64/e2f4350a54440b272fea7a52f370f55f3b7455586f2cd0233874d5f3cdd99864/node_modules/@openai/codex/vendor/x86_64-unknown-linux-musl/bin/codex\", \"install method\": \"pnpm (package /home/johnlin/.local/share/pnpm/store/v11/links/@openai/codex/0.144.4-linux-x64/e2f4350a54440b272fea7a52f370f55f3b7455586f2cd0233874d5f3cdd99864/node_modules/@openai/codex/vendor/x86_64-unknown-linux-musl, bin /home/johnlin/.local/share/pnpm/store/v11/links/@openai/codex/0.144.4-linux-x64/e2f4350a54440b272fea7a52f370f55f3b7455586f2cd0233874d5f3cdd99864/node_modules/@openai/codex/vendor/x86_64-unknown-linux-musl/bin, resources /home/johnlin/.local/share/pnpm/store/v11/links/@openai/codex/0.144.4-linux-x64/e2f4350a54440b272fea7a52f370f55f3b7455586f2cd0233874d5f3cdd99864/node_modules/@openai/codex/vendor/x86_64-unknown-linux-musl/codex-resources, path /home/johnlin/.local/share/pnpm/store/v11/links/@openai/codex/0.144.4-linux-x64/e2f4350a54440b272fea7a52f370f55f3b7455586f2cd0233874d5f3cdd99864/node_modules/@openai/codex/vendor/x86_64-unknown-linux-musl/codex-path)\", \"platform\": \"linux-x86_64\", \"version\": \"0.144.4\" }, \"remediation\": null, \"durationMs\": 0 }, \"runtime.search\": { \"id\": \"runtime.search\", \"category\": \"search\", \"status\": \"ok\", \"summary\": \"search is OK (bundled)\", \"details\": { \"search command\": \"/home/johnlin/.local/share/pnpm/store/v11/links/@openai/codex/0.144.4-linux-x64/e2f4350a54440b272fea7a52f370f55f3b7455586f2cd0233874d5f3cdd99864/node_modules/@openai/codex/vendor/x86_64-unknown-linux-musl/codex-path/rg\", \"search command readiness\": \"file exists\", \"search provider\": \"bundled\" }, \"remediation\": null, \"durationMs\": 0 }, \"sandbox.helpers\": { \"id\": \"sandbox.helpers\", \"category\": \"sandbox\", \"status\": \"ok\", \"summary\": \"sandbox configuration is readable\", \"details\": { \"approval policy\": \"Never\", \"codex-linux-sandbox helper\": \"/home/johnlin/.codex/tmp/arg0/codex-arg0okULxf/codex-linux-sandbox\", \"execve wrapper helper\": \"/home/johnlin/.codex/tmp/arg0/codex-arg0okULxf/codex-execve-wrapper\", \"filesystem sandbox\": \"unrestricted\", \"network sandbox\": \"enabled\" }, \"remediation\": null, \"durationMs\": 0 }, \"state.paths\": { \"id\": \"state.paths\", \"category\": \"state\", \"status\": \"ok\", \"summary\": \"state paths and databases are inspectable\", \"details\": { \"CODEX_HOME\": \"/home/johnlin/.codex (dir)\", \"active rollout files\": \"54 files, 10921537 total bytes, 202250 average bytes\", \"archived rollout files\": \"0 files, 0 total bytes, 0 average bytes\", \"goals DB\": \"/home/johnlin/.codex/goals_1.sqlite (file)\", \"goals DB integrity\": \"ok\", \"log DB\": \"/home/johnlin/.codex/logs_2.sqlite (file)\", \"log DB integrity\": \"ok\", \"log dir\": \"/home/johnlin/.codex/log (missing)\", \"memories DB\": \"/home/johnlin/.codex/memories_1.sqlite (file)\", \"memories DB integrity\": \"ok\", \"sqlite home\": \"/home/johnlin/.codex (dir)\", \"state DB\": \"/home/johnlin/.codex/state_5.sqlite (file)\", \"state DB integrity\": \"ok\" }, \"remediation\": null, \"durationMs\": 67 }, \"state.rollout_db_parity\": { \"id\": \"state.rollout_db_parity\", \"category\": \"threads\", \"status\": \"ok\", \"summary\": \"rollout files and state DB thread inventory agree\", \"details\": { \"default model provider\": \"openai_https\", \"rollout DB active files\": \"54\", \"rollout DB active rows\": \"54\", \"rollout DB archive mismatches\": \"0\", \"rollout DB archived files\": \"0\", \"rollout DB archived rows\": \"0\", \"rollout DB duplicate DB paths\": \"0\", \"rollout DB duplicate rollout thread ids\": \"0\", \"rollout DB malformed file names\": \"0\", \"rollout DB missing active rows\": \"0\", \"rollout DB missing archived rows\": \"0\", \"rollout DB model providers\": \"openai_https=54\", \"rollout DB rows\": \"54\", \"rollout DB scan cap reached\": \"false\", \"rollout DB scan errors\": \"0\", \"rollout DB sources\": \"exec=24, cli=21, vscode=9\", \"rollout DB stale rows\": \"0\" }, \"remediation\": null, \"durationMs\": 127 }, \"system.environment\": { \"id\": \"system.environment\", \"category\": \"system\", \"status\": \"ok\", \"summary\": \"OS language zh-CN\", \"details\": { \"EDITOR\": \"set\", \"LANG\": \"zh_CN.UTF-8\", \"VISUAL\": \"not set\", \"os\": \"Fedora 44.0.0 [64-bit]\", \"os language\": \"zh-CN\", \"os type\": \"Fedora\", \"os version\": \"44.0.0\" }, \"remediation\": null, \"durationMs\": 4 }, \"terminal.env\": { \"id\": \"terminal.env\", \"category\": \"terminal\", \"status\": \"ok\", \"summary\": \"terminal metadata was detected\", \"details\": { \"COLORTERM\": \"truecolor\", \"DISPLAY\": \"present\", \"TERMINFO\": \"/usr/share/terminfo (dir)\", \"TERM_PROGRAM\": \"ghostty\", \"WAYLAND_DISPLAY\": \"present\", \"color output\": \"enabled\", \"effective locale\": \"zh_CN.UTF-8\", \"stderr is terminal\": \"true\", \"stdin is terminal\": \"true\", \"stdout is terminal\": \"true\", \"terminal\": \"Ghostty\", \"terminal size\": \"179x46\", \"terminal version\": \"1.3.1-2.fc44\" }, \"remediation\": null, \"durationMs\": 0 }, \"terminal.title\": { \"id\": \"terminal.title\", \"category\": \"title\", \"status\": \"ok\", \"summary\": \"terminal title default\", \"details\": { \"terminal title activity\": \"true\", \"terminal title items\": \"activity, project-name\", \"terminal title project source\": \"cwd\", \"terminal title project value\": \"Dev\", \"terminal title source\": \"default\" }, \"remediation\": null, \"durationMs\": 0 }, \"updates.status\": { \"id\": \"updates.status\", \"category\": \"updates\", \"status\": \"ok\", \"summary\": \"update configuration is locally consistent\", \"details\": { \"cached latest version\": \"0.144.4\", \"check for update on startup\": \"true\", \"dismissed version\": \"0.144.4\", \"last checked at\": \"2026-07-15T05:28:03.442999221Z\", \"latest version\": \"0.144.4\", \"latest version status\": \"current version is not older\", \"update action\": \"pnpm add -g @openai/codex\", \"version cache\": \"/home/johnlin/.codex/version.json\" }, \"remediation\": null, \"durationMs\": 916 } } } ``` ### What issue are you seeing? MCP server tools are invisible to the model when using a non-OpenAI Responses API endpoint. codex packages each MCP server's tools into a single OpenAI Responses API **namespace** tool (`{\"type\":\"namespace\",\"name\":\"mcp__\",\"tools\":[{\"type\":\"function\",...}]}`). Non-OpenAI-compatible endpoints only accept `{\"type\":\"function\"}` tools and silently ignore the `namespace` container, so the model never sees any of the MCP server's tools — only the built-in tools (`exec_command`, `write_stdin`, `list_mcp_resources`, `list_mcp_resource_templates`, `read_mcp_resource`, `update_plan`, `view_image`, `update_goal`, …). ### What steps can reproduce the bug? 1. Configure codex with a non-OpenAI OpenAI-compatible endpoint (e.g. `deepseek-v4-pro` via a third-party proxy, `wire_api = \"responses\"`) and any stdio MCP server that exposes tools (e.g. a local MCP server with `tools/list` returning N tools). 2. Run: `codex exec \"List the exact names of all tools available to you, one per line.\"` 3. Observe the model lists only built-in tools. **None** of the MCP server's tools appear. 4. `RUST_LOG=trace codex exec \"hi\"` shows the MCP tools **are** fetched: `listed MCP server tools server_name= tool_count=N` (e.g. 33), but `build_model_visible` reports them merged into a namespace container (e.g. `final specs=14 namespace=2`) that the endpoint ignores. Repro summary: codex successfully fetches the MCP server's tools (the MCP/stdio layer is fine), but they are serialized as a `namespace` tool type that the endpoint doesn't understand, so they never reach the model. ### What is the expected behavior? MCP server tools should be callable by the model on any Responses-API-compatible endpoint. When the endpoint doesn't support the `namespace` tool type, codex should degrade gracefully — either emit the MCP tools as plain `{\"type\":\"function\"}` tools, or expose a way to opt out of the namespace grouping. ### Additional information **Root cause** (codex-rs, current `main`): - `core/src/tools/handlers/mcp.rs` `create_tool_spec` wraps every MCP tool in `ToolSpec::Namespace(ResponsesApiNamespace{...})`, which serializes to `{\"type\":\"namespace\",...}` (an OpenAI Responses API tool type; `tools/src/responses_api.rs`, `tool_spec.rs`). - `merge_into_namespaces` (`core/src/tools/spec_plan.rs`) coalesces same-namespace tools into one container (intended for prompt-size / grouping optimization). - The `namespace_tools` provider capability (`model-provider/src/provider.rs`) looks like the intended escape hatch, but when `false` the namespace tools are **filtered out entirely** (`spec_plan.rs`: `namespace_tools_enabled || !Namespace`) rather than expanded — so the model still can't use them. Note: every provider currently defaults to `namespace_tools = true` (including Bedrock, which only disables `image_generation`/`web_search`), so the `false` branch is never exercised in practice — the escape hatch exists but is not wired up to a working degradation path. - Non-OpenAI endpoints don't implement the `namespace` tool type (nor the `defer_loading` field), so the container is silently dropped. **Proposed fix :** Extend the `namespace_tools = false` path to **expand** namespace containers into individual `{\"type\":\"function\"}` tools (instead of dropping them), plus a dispatch fallback in `ToolRegistry::tool` (`core/src/tools/registry.rs`) so tool calls arriving with `namespace=None` (plain functions carry no namespace field; `build_tool_call` in `router.rs` reads `ToolName::new(namespace, name)`) still match the registered `McpHandler` by name. The OpenAI path (`namespace_tools = true`) stays unchanged, preserving the namespace/grouping + deferred-loading optimization. A provider that doesn't support the namespace tool type would declare `namespace_tools = false`. I've validated this direction with a patched build: on a `deepseek-v4-pro` endpoint, the model lists and successfully calls MCP tools (e.g. `search_semantic` + `entry_get` returning real results). Happy to open a PR by invitation if this aligns with the team's intended direction. Pointers to the relevant code are above; happy to refine the approach based on maintainer feedback.", "url": "https://github.com/openai/codex/issues/33263", "createdAt": "2026-07-15T06:07:41Z", "updatedAt": "2026-08-13T02:25:15Z", "timestamp": "2026-08-13T02:25:15Z", "metrics": { "reactions": 0, "comments": 4 }, "labels": [ "bug", "mcp", "CLI", "custom-model" ], "author": "Lin-Jiong-HDU", "state": "open", "assignees": [] }, { "id": "github:openai/codex:issue:33286", "source": "github", "group": "coding-agent-infrastructure", "project": "openai/codex", "kind": "issue", "title": "Codex/ChatGPT update deleted all the conversations", "text": "### What version of the Codex App are you using (From “About Codex” dialog)? Codex, Chat GPT -5 ### What subscription do you have? free ### What platform is your computer? uname -mprs ### What issue are you seeing? After updating ChatGPT with Codex app on macOS on July 15, 2026, my entire chat history disappeared. I am signed in with the same email address and sign-in method as before. These are not chats that I deleted. They disappeared immediately after the update. The app now displays only the new chat created today. So I lost all my chats. This means hundreds hours of work & research ! I am VERY UPSET The new chatGPT-5/Codex is completely useless and cannot restaure anything. Local conversation archives still exist on my Mac but cannot be restaured, which appears to indicate a synchronization or indexing issue after the update. I recommend NOT TO UPDATE WITH CODEX Date and time zone of the incident: July 15, 2026, Asia/Bangkok. ### What steps can reproduce the bug? ? ### What is the expected behavior? ? ### Additional information _No response_", "url": "https://github.com/openai/codex/issues/33286", "createdAt": "2026-07-15T07:57:43Z", "updatedAt": "2026-08-12T15:36:29Z", "timestamp": "2026-08-12T15:36:29Z", "metrics": { "reactions": 3, "comments": 3 }, "labels": [ "bug", "app", "session" ], "author": "Khalagasser", "state": "open", "assignees": [], "change": "updated" }, { "id": "github:openai/codex:issue:33287", "source": "github", "group": "coding-agent-infrastructure", "project": "openai/codex", "kind": "issue", "title": "[macOS] Chrome sessions become unavailable after Codex uses Chrome and Chrome is relaunched", "text": "### What version of the Codex App are you using (From “About Codex” dialog)? 26.707.72221 (build 5307) ### What subscription do you have? ChatGPT paid subscription (exact tier is not exposed in the diagnostics used for this report) ### What platform is your computer? Darwin 25.5.0 arm64 arm ### What issue are you seeing? ## Summary On macOS, all authenticated website sessions in the user's normal Google Chrome profile became unavailable after Codex had used that Chrome instance and Chrome was later quit and relaunched. This has happened twice. Chrome then displayed this banner: > Relaunch your browser to load your profile data and keep it encrypted The accounts appeared signed out across multiple unrelated sites (including GitHub). The evidence suggests that the cookies may still exist but Chrome cannot decrypt them through macOS Keychain. ## Observed system evidence On every fresh Chrome launch during the second occurrence, macOS logged: ``` MacOS error: -25337 CSSMERR_CSP_OPERATION_AUTH_DENIED error while checking integrity, denying access ``` Five consecutive Chrome launches produced the same Keychain denial. The `Chrome Safe Storage` item still exists in the user's login keychain. Its Access Control tab says access is unrestricted / all applications may access it. However, a read-only `security` probe from the Codex environment returns exit code 51 (authorization failed) without reading or displaying the secret. Chrome's code signature verifies successfully and Gatekeeper reports a notarized Developer ID application. No evidence of application tampering was found. Chrome had auto-updated to `150.0.7871.124` while an older Chrome process remained open. The failure became visible only after that existing process was quit normally and the updated process started. ## Codex correlation Codex Chrome/Computer Use had interacted with the already-running visible Chrome instance earlier that evening. The local Codex session history contains no Chrome, Browser, or Computer Use action at the time Chrome quit. macOS recorded a clean user-initiated quit with exit status 0, not a crash. In an earlier occurrence, Codex/Computer Use launched Chrome while the macOS login keychain was locked. Chrome then logged the same Safe Storage/metadata decryption failures and several sites required login again. No Codex action that clears cookies, resets the profile, or deletes browser data was found. ### What steps can reproduce the bug? The issue has occurred twice but is not yet deterministic. ### Second occurrence 1. Keep the user's normal signed-in Chrome profile running. 2. Allow Codex Chrome/Computer Use to interact with that already-running Chrome instance. 3. Chrome auto-updates in the background while the existing process remains open. 4. Quit Chrome normally. 5. Relaunch Chrome. 6. Observe the banner asking to relaunch to load profile data and keep it encrypted. 7. Observe that multiple unrelated websites are signed out. 8. Check macOS unified logs for the new Chrome PID; each launch reports OSStatus `-25337`, `CSSMERR_CSP_OPERATION_AUTH_DENIED`, and an integrity-check denial. ### Earlier occurrence 1. Start a Codex task that launches/uses the user's normal Chrome profile while the macOS login keychain is locked or unavailable. 2. Chrome starts but cannot decrypt Safe Storage/profile metadata. 3. After the keychain becomes available, multiple site sessions still appear unavailable. A full backup of the Chrome profile, login keychain, preferences, updater state, and Chrome application was made before attempting remediation. No Keychain item has been deleted or reset. ### What is the expected behavior? Codex should be able to use an existing Chrome session without changing the user's Keychain trust state or making the profile's encrypted cookies unavailable. If the macOS login keychain or `Chrome Safe Storage` cannot be accessed, the Chrome integration should detect that condition and stop with a clear warning instead of launching or continuing against the user's normal profile. After Codex finishes and Chrome is quit/relaunched, existing website sessions should remain readable and signed in. ### Additional information ## Versions and timing - Codex App: `26.707.72221` (build `5307`) - Chrome: `150.0.7871.124` - Platform: `Darwin 25.5.0 arm64 arm` - Chrome update installed before the second occurrence; the symptom appeared at the first relaunch afterward. ## Related public issues reviewed No exact duplicate was found for `Chrome Safe Storage`, mass logout, lost cookies, or encrypted profile data. Possibly related but not duplicates: - #24204: Codex sandbox cannot access macOS Keychain after an update. - #28990: Codex App Keychain/OSStatus failure while generating a remote-control keypair. - #32925 / #32951: recent Browser/Chrome plugin initialization regression; those fail before browser discovery and reports say the signed-in Chrome state remains intact. - #28352: orphaned headless Chrome workers using temporary profiles. Please investigate whether the Codex Chrome native host, Chrome plugin, or Computer Use launch path can interact badly with a locked/desynchronized macOS login keychain, especially across a Chrome auto-update and relaunch. Sanitized unified-log excerpts and a precise local timeline are available if maintainers need them. No cookies, passwords, Keychain secrets, local usernames, account IDs, or private URLs are included in this report.", "url": "https://github.com/openai/codex/issues/33287", "createdAt": "2026-07-15T08:17:22Z", "updatedAt": "2026-08-12T17:58:20Z", "timestamp": "2026-08-12T17:58:20Z", "metrics": { "reactions": 0, "comments": 1 }, "labels": [ "bug", "app", "computer-use", "browser" ], "author": "jimmycarp966", "state": "open", "assignees": [] }, { "id": "github:openai/codex:issue:33344", "source": "github", "group": "coding-agent-infrastructure", "project": "openai/codex", "kind": "issue", "title": "Bug: Weekly quota not reset in July 14 global reset (8M users milestone)", "text": "What issue are you seeing? On July 14, 2026, Tibo announced a global usage limit reset for all Codex users to celebrate reaching 8 million active users: https://x.com/thsottiaux/status/2077114635308986427 However, my account did not receive this reset. My weekly quota remains at 0% with a reset date of July 20 — unchanged from before the announcement. Other users in my network confirmed they received the reset, so this appears to be an account-specific miss rather than a delayed rollout. This is the same pattern as issue #27027 (June 4 global reset not applied to some accounts). What steps can reproduce the bug? 1. Have a business workspace account with exhausted weekly quota 2. A global reset is announced by the Codex team 3. Check the Usage UI — the reset date and quota percentage remain unchanged while other accounts receive the reset Screenshot See attached: after the July 14 reset announcement, the Usage UI still shows 0% remaining with a July 20 reset date. Expected behavior Global resets announced for \"all\" users should apply to all paid accounts, including business workspace accounts. Additional information - Desktop app, latest version - This is a recurring issue — #27027 documents the same problem from the June 4 reset - The Usage UI provides no visibility into whether a special reset event was applied or skipped for a given account \"Image\"", "url": "https://github.com/openai/codex/issues/33344", "createdAt": "2026-07-15T13:57:52Z", "updatedAt": "2026-08-13T16:51:03Z", "timestamp": "2026-08-13T16:51:03Z", "metrics": { "reactions": 0, "comments": 3 }, "labels": [ "bug", "rate-limits", "app" ], "author": "caijinghui", "state": "open", "assignees": [] }, { "id": "github:openai/codex:issue:33493", "source": "github", "group": "coding-agent-infrastructure", "project": "openai/codex", "kind": "issue", "title": "Local compaction v2 retains unbounded input_image payloads, causing repeated auto-compaction", "text": "### What version of Codex is running? - Codex Desktop: `26.707.72221` - Embedded CLI: `codex-cli 0.144.2` - Platform: macOS 26.3 (Build 25D125), Apple Silicon - Model: `gpt-5.6-sol` ### What issue are you seeing? A long-running, image-heavy Codex Desktop thread enters a repeated auto-compaction cycle. After a compaction completes, the resulting history remains only slightly below the auto-compaction threshold. Even a short new question pushes it over the threshold again, so almost every new turn starts with another compaction. The compacted `replacement_history` keeps historical `input_image` items, including their full inline base64/data-URL payloads. Repeated compactions keep copying the same images into new compacted records. This produces two related effects: 1. The post-compaction prompt remains close to the context threshold, causing immediate re-compaction on subsequent turns. 2. The rollout JSONL grows rapidly because the same inline image payloads are persisted repeatedly. ### Local evidence From one affected thread: | Metric | Observed value | | --- | ---: | | Rollout JSONL size | approximately 4.16 GB | | Compaction records | 224 | | Images retained by the latest compacted replacement history | 92 | | Retained inline image/base64 characters | approximately 26.47 million | | Retained text characters | approximately 188,000 | | Effective context window reported for the session | 258,400 tokens | | Default auto-compaction threshold | approximately 244,800 tokens | | Prompt size immediately after compaction | approximately 236,000-237,000 tokens | The post-compaction history therefore has only about 8,000 tokens of headroom. A normal follow-up turn is sufficient to trigger compaction again. No full rollout is attached because it contains private prompts, paths, tool output, and images. I can provide additional redacted structural statistics if needed. ### Steps to reproduce 1. Use a long-running Codex Desktop thread containing multiple pasted screenshots or image inputs. 2. Continue until local/remote-v2 compaction occurs. 3. Inspect the newest `type: \"compacted\"` rollout record. 4. Confirm that `payload.replacement_history` retains user messages containing `input_image` data URLs. 5. Send a short follow-up question. 6. Observe another automatic compaction even though the previous compaction just completed. 7. Repeat several turns and observe the rollout file growing as image payloads are copied into additional compacted records. ### Expected behavior After compaction: - Retained multimodal history should be bounded by a realistic image/token/byte budget. - There should be enough hysteresis below the auto-compaction threshold for ordinary follow-up turns. - Old inline image payloads should not be duplicated indefinitely in every compacted rollout record. ### Actual behavior The current retained-message text budget treats images as zero text tokens and preserves them: ```rust ContentItem::InputImage { .. } => 0, ``` and later: ```rust ContentItem::InputImage { .. } => truncated_content.push(content_item), ``` The message-level `.max(1)` floor limits the number of image-only messages only very weakly. It does not account for image cost inside mixed text/image messages, image count, encoded byte size, or vision-token cost. Current source: - `codex-rs/core/src/compact_remote_v2.rs` - `message_text_token_count` - `truncate_message_text_to_token_budget` - `truncate_retained_messages_for_remote_compaction` ### Possible fix direction For active compacted history: 1. Give retained images a conservative estimated token cost, using the existing image-size/detail estimator where possible. 2. Add explicit caps for retained image count and/or encoded bytes. 3. Keep the newest images first and replace older images with a lightweight placeholder once the image budget is exhausted. 4. Add a regression test with many mixed text/image messages verifying that compacted history is bounded and a short next turn does not immediately trigger compaction again. For rollout persistence, consider storing images as content-addressed blobs or references rather than repeating full base64 strings. That storage concern may be better handled separately under the existing image-heavy rollout issue. ### Related issues - #24388: same underlying retained-`input_image` problem, closed after the compaction architecture changed; this report reproduces the behavior on the newer local compaction path. - #24550: large inline images in compacted `replacement_history` cause Responses WebSocket fallback. - #24676: image-heavy rollout JSONL causes Codex Desktop hangs and difficult session recovery. - #9601: images can poison context estimation after history mutation. I am willing to help with additional redacted diagnostics, test-case design, or an implementation if maintainers agree on the approach and invite a PR under the repository contribution policy.", "url": "https://github.com/openai/codex/issues/33493", "createdAt": "2026-07-16T04:01:14Z", "updatedAt": "2026-08-13T12:54:36Z", "timestamp": "2026-08-13T12:54:36Z", "metrics": { "reactions": 6, "comments": 11 }, "labels": [ "bug", "context", "app" ], "author": "snrui", "state": "open", "assignees": [] }, { "id": "github:openai/codex:issue:33552", "source": "github", "group": "coding-agent-infrastructure", "project": "openai/codex", "kind": "issue", "title": "macOS Codex Desktop 26.707.91948 still overrides custom profile with never/user", "text": "### What version of the Codex App are you using (From “About Codex” dialog)? Codex Desktop `26.707.91948` (build `5440`) Bundled Codex CLI: `0.144.5` ### What subscription do you have? Not included in this public report. ### What platform is your computer? ```text Darwin 25.5.0 arm64 arm macOS 26.5.2 (25F84) ``` ### What issue are you seeing? After fully quitting and restarting Codex Desktop, a completely fresh conversation still overrides the separately configured approval policy and approval reviewer when using a named custom permission profile. The configuration contains: ```toml approval_policy = \"on-request\" approvals_reviewer = \"auto_review\" default_permissions = \"\" ``` The first turn of the fresh Desktop conversation recorded: ```text originator = Codex Desktop source = vscode cli_version = 0.144.5 approval_policy = never approvals_reviewer = user permission_profile.type = managed sandbox_policy.type = workspace-write ``` The managed permission profile itself was applied, including its configured additional writable roots. However, the independent approval settings were changed from `on-request/auto_review` to `never/user`. The bundled `codex doctor --json` loads the same configuration successfully: ```text config.load.status = ok config.load.summary = config loaded sandbox.helpers.approval policy = OnRequest filesystem sandbox = restricted network sandbox = enabled ``` Because the fresh thread runs with `approval_policy = never`, escalation requests are unavailable and auto-review cannot run. ### What steps can reproduce the bug? 1. Configure `approval_policy = \"on-request\"`, `approvals_reviewer = \"auto_review\"`, and a valid named custom `default_permissions` profile. 2. Fully quit Codex Desktop with Cmd-Q. 3. Reopen Codex Desktop `26.707.91948`. 4. Create a completely new conversation. 5. Ask the first turn to report the task-injected runtime values for `approval_policy`, `approvals_reviewer`, `permission_profile.type`, and `sandbox_policy.type` without reading `config.toml`. 6. Inspect the first turn context. The new conversation receives `never/user/managed/workspace-write` instead of the configured `on-request/auto_review` approval settings. ### What is the expected behavior? A named permission profile should control filesystem and network permissions without replacing the independently configured approval policy and reviewer. The fresh thread should start with: ```text approval_policy = on-request approvals_reviewer = auto_review permission_profile.type = managed sandbox_policy.type = workspace-write ``` ### Additional information This is the macOS Codex Desktop counterpart to #33084. That issue was closed after the reporter confirmed the VS Code case appeared fixed in `26.707.91948`, but the Desktop reproduction above still occurs on that exact version after a full restart. Related broader Desktop report: #32338.", "url": "https://github.com/openai/codex/issues/33552", "createdAt": "2026-07-16T09:14:06Z", "updatedAt": "2026-08-13T03:33:24Z", "timestamp": "2026-08-13T03:33:24Z", "metrics": { "reactions": 0, "comments": 2 }, "labels": [ "bug", "sandbox", "app", "config" ], "author": "liby", "state": "open", "assignees": [] }, { "id": "github:openai/codex:issue:33713", "source": "github", "group": "coding-agent-infrastructure", "project": "openai/codex", "kind": "issue", "title": "[Regression] In-app Browser and Chrome extension still wait ~30s on ab.chatgpt.com Statsig timeouts in VPN TUN mode", "text": "### What issue are you seeing? This appears to be a regression or an incomplete fix for #29385, which was closed as completed on 2026-07-14. On the latest Codex/ChatGPT Desktop build, both the in-app Browser and the Chrome extension can eventually navigate to a normal webpage, but the browser-control operation still takes about 30.5–30.7 seconds. During the wait, the browser client logs 10-second Statsig request timeouts to `ab.chatgpt.com`. Current measurements for `https://example.com/`: | Browser surface | Result | Elapsed time | | --- | --- | ---: | | Codex in-app Browser | Success; title `Example Domain` | 30743 ms | | Codex Chrome extension | Success; title `Example Domain` | 30584 ms | The in-app Browser logged both: ```text ERROR [Statsig] POST https://ab.chatgpt.com/v1/initialize?... Timeout of 10000ms expired. ERROR [Statsig] POST https://ab.chatgpt.com/v1/rgstr?... Timeout of 10000ms expired. ``` The Chrome extension path logged: ```text ERROR [Statsig] POST https://ab.chatgpt.com/v1/rgstr?... Timeout of 10000ms expired. ``` The requested webpage is reachable and returns the correct URL/title. However, the browser operation completes only after the ambient Statsig requests time out. Since the total duration is slightly above 30 seconds, this can still surface as a browser-call timeout even though the requested page itself is reachable. ### Environment ```text Codex/ChatGPT Desktop: 26.715.21316 (5484) Codex CLI: 0.145.0-alpha.18 In-app Browser plugin: openai-bundled/browser/26.715.21316 Chrome plugin: openai-bundled/chrome/26.715.21316 Google Chrome: 150.0.7871.116 macOS: 26.5.2 (25F84) Architecture: arm64 ``` The same approximately 30-second symptom was also reproducible before updating, with Browser/Chrome plugin build `26.707.91948`. ### VPN / proxy details A VPN was already running continuously in **TUN mode** before Codex and Chrome were launched; it was not enabled only for this test. The VPN connection dashboard confirms that both processes: - `codex` - `Codex (Service)` created HTTPS connections to `ab.chatgpt.com:443`, and both connections were matched to the active proxy node. This indicates that Codex traffic to this hostname is being captured and routed by the TUN proxy. In a normal Chrome tab, opening `https://ab.chatgpt.com/` returns an HTTP response immediately: ```text RBAC: access denied ``` That response is expected for an unauthenticated direct page request, but it confirms that Chrome can resolve, connect to, and receive an HTTP response from the hostname through the current network path. Despite that, the browser-client Statsig POST requests still expire after 10000 ms. ### Steps to reproduce 1. On macOS, enable a VPN in TUN mode before starting Codex. 2. Confirm that Codex traffic to `ab.chatgpt.com:443` is routed through the active proxy node. 3. Start Codex Desktop with the in-app Browser and Chrome plugins installed. 4. With the in-app Browser, create a tab and navigate to `https://example.com/`. 5. Verify that the page eventually returns `https://example.com/` and title `Example Domain`. 6. Observe that the operation takes about 30 seconds and logs 10-second Statsig timeouts for `/v1/initialize` and/or `/v1/rgstr`. 7. Repeat through the Codex Chrome extension. 8. Observe the same approximately 30-second completion time and Statsig timeout pattern. ### Expected behavior Non-critical Statsig initialization and event logging should not block or delay a user-requested browser operation. If `ab.chatgpt.com` is temporarily unreachable from the browser-client network context, these requests should fail open quickly or run independently from the critical navigation path. If the process is expected to honor the system/TUN proxy, its privileged network path should use the same effective routing as the rest of the Codex application. A successful navigation to a reachable target page should return well within the normal browser-call timeout. ### Troubleshooting already attempted - Updated Codex/ChatGPT Desktop to the latest available build. - Restarted Codex. - Restarted Chrome. - Reinstalled the Codex Chrome extension. - Restarted macOS. - Repeated the test after the application/plugin update. - Confirmed through the VPN dashboard that both `codex` and `Codex (Service)` connections to `ab.chatgpt.com:443` use the proxy node. The behavior remains reproducible on both browser surfaces. ### Related issues - #29385 — same in-app Browser/Chrome ambient timeout problem; closed as completed, but still reproducible on build `26.715.21316`. - #30841 — overlaps with the ambient ~30-second delay, but also reports a separate deep-control/CDP bridge hang. This report is limited to the shared Statsig delay that affects both normal Browser surfaces.", "url": "https://github.com/openai/codex/issues/33713", "createdAt": "2026-07-17T01:10:54Z", "updatedAt": "2026-08-12T17:42:34Z", "timestamp": "2026-08-12T17:42:34Z", "metrics": { "reactions": 0, "comments": 4 }, "labels": [ "bug", "app", "connectivity", "browser", "performance" ], "author": "earthking11", "state": "open", "assignees": [] }, { "id": "github:openai/codex:issue:33730", "source": "github", "group": "coding-agent-infrastructure", "project": "openai/codex", "kind": "issue", "title": "Codex Desktop: keep active tasks visible in a persistent sidebar section", "text": "### What variant of Codex are you using? Codex Desktop app ### What feature would you like to see? When the sidebar contains many projects and tasks, it becomes difficult to find a task that is still running—especially when several tasks are active across different projects at the same time. Today, active tasks are mixed into the normal project/thread hierarchy. They may be outside the visible scroll area or hidden inside a collapsed project, so checking progress often means scanning multiple projects and long task lists. Please add a persistent, global **Active tasks** section to the sidebar. For example, it could be pinned at the bottom (or top) of the sidebar and remain visible while the rest of the task list scrolls. Suggested behavior: - Show every task/thread with a currently running turn, across all projects. - Keep the section visible even when its project is collapsed or outside the current scroll position. - Clicking an item should immediately navigate to that task. - Show a compact state such as running, waiting for approval/input, or reconnecting. - Remove the item when the turn reaches a terminal state. - If there are no active tasks, hide or collapse the section. The exact placement is flexible; the important part is having a stable, one-click way to locate all in-progress tasks. ### Why this matters Codex encourages parallel, long-running work. A typical workflow may have several tasks running in different projects while the user continues working elsewhere. In a crowded sidebar, the tasks that need attention are harder to find than completed history. A persistent active-task area would turn the sidebar into a lightweight task monitor and make parallel sessions much easier to supervise without changing the existing project organization. ### Expected behavior At any time, I can see all currently active tasks in one stable sidebar location and jump to any of them with one click, regardless of project, sidebar scroll position, or whether the project is collapsed. ### Additional information This is specifically about discoverability and navigation for active tasks in the Desktop app, rather than general thread pinning or multi-window support. I searched for existing issues around active/running sessions, sidebar navigation, pinned tasks, and multi-task workflows. I found related requests such as #33205 (multi-window workflows), but not this persistent active-task switcher request.", "url": "https://github.com/openai/codex/issues/33730", "createdAt": "2026-07-17T03:27:31Z", "updatedAt": "2026-08-13T05:33:30Z", "timestamp": "2026-08-13T05:33:30Z", "metrics": { "reactions": 1, "comments": 3 }, "labels": [ "enhancement", "app", "session" ], "author": "vorojar", "state": "open", "assignees": [] }, { "id": "github:openai/codex:issue:33796", "source": "github", "group": "coding-agent-infrastructure", "project": "openai/codex", "kind": "issue", "title": "Windows Desktop: multiple 1–2 GB rollout sessions trigger ~71 Mbps upstream bursts during resume", "text": "### What version of the Codex App are you using (From “About Codex” dialog)? 26.715.2305.0 ### What subscription do you have? ChatGPT subscription (exact tier was not exposed by the local diagnostics used for this report) ### What platform is your computer? Microsoft Windows NT 10.0.26100.0 x64 ### What issue are you seeing? Codex Desktop intermittently saturates upstream bandwidth while multiple very large rollout/session files are active or being resumed. This was measured locally rather than inferred from Task Manager alone: - During an 8-second affected interval, the active WLAN adapter averaged about **8.9 MB/s upload (~71 Mbps)** while download was about **0.27 MB/s**. - The I/O spike was concentrated in the Codex Desktop app-server process and ChatGPT renderer/network-service processes. - The traffic used HTTPS connections directly and through a local loopback proxy. The proxy was only forwarding the traffic; Codex/ChatGPT processes were the source. - During a later 12-second idle interval, upload dropped to about **0.03 MB/s average** (0–0.15 MB/s), so this is a burst associated with active/resuming work rather than constant background traffic. - The local session store contained 245 rollout JSONL files totaling about **23.9 GB**. - **15 rollout files were larger than 1 GB**; the largest was about **2.0 GB**. - Several 1.6–2.0 GB rollout files were being modified during the affected period. - More than 20 `node_repl` tool-runtime child processes were present under Codex. No packet payloads, account identifiers, local paths, repository names, remote addresses, credentials, or session contents are included in this report. This appears related to #19643, #20805, and #21948, but the observed failure mode here is specifically Codex Desktop on Windows with multiple 1–2 GB rollout files and measurable high-upstream bursts during active/resume behavior. ### What steps can reproduce the bug? The exact minimal trigger is not yet known, but this is the observed workflow: 1. Use Codex Desktop on Windows for long-running browser, computer-use, image, or tool-heavy sessions. 2. Accumulate multiple large rollout JSONL files; in this case several reached approximately 1.6–2.0 GB. 3. Leave several such sessions active/unarchived, or resume/open them while Codex tool runtimes are still present. 4. Monitor adapter throughput and per-process I/O. 5. Observe Codex/Desktop processes producing large upstream bursts that can saturate the connection. 6. Let the work become idle; upstream traffic returns close to zero. Session IDs are intentionally omitted because the associated rollouts may contain private repository and browser context. I can provide additional sanitized aggregate diagnostics if maintainers specify what counters are needed. ### What is the expected behavior? - Session resume/hydration should not retransmit or repeatedly process unbounded embedded history. - Oversized image/browser/tool artifacts should be deduplicated, externalized, or incrementally referenced. - Inactive oversized sessions should not cause network activity in unrelated active work. - Upload bandwidth should be bounded and backpressured. - The app should identify which session/task is sending data and warn when rollout size becomes abnormal. - Tool-runtime child processes should be cleaned up when their task has finished. ### Additional information The strongest local correlation is between the upload bursts and several concurrently active 1.6–2.0 GB rollout files. This does not prove that every byte of those files was uploaded, but it strongly suggests an unbounded session hydration/reconnect or artifact-handling path. Related issues: - #19643 — sustained upload saturation during image-related Codex tasks - #20805 — image-heavy chats repeatedly reconnect - #21948 — oversized browser-heavy session degrades the whole Windows app - #22004 — very large rollout JSONL files and desktop process limits", "url": "https://github.com/openai/codex/issues/33796", "createdAt": "2026-07-17T09:45:49Z", "updatedAt": "2026-08-13T15:43:17Z", "timestamp": "2026-08-13T15:43:17Z", "metrics": { "reactions": 0, "comments": 5 }, "labels": [ "bug", "windows-os", "app", "connectivity", "session" ], "author": "suiyuebaobao", "state": "open", "assignees": [] }, { "id": "github:openai/codex:issue:33875", "source": "github", "group": "coding-agent-infrastructure", "project": "openai/codex", "kind": "issue", "title": "High CPU Usage Triggered by Windows Defender & WMI When Launching Codex Desktop on Windows 10", "text": "### What version of the Codex App are you using (From “About Codex” dialog)? Codex Desktop Version: 26.715.2305.0 ### What subscription do you have? pro 20x ### What platform is your computer? windows ### What issue are you seeing? High CPU Usage Triggered by Windows Defender & WMI When Launching Codex Desktop on Windows 10 Environment OS: Windows 10 Pro x64 CPU: Intel Core i5-10400F RAM: 16 GB GPU: NVIDIA GTX 1650 Codex Desktop Version: 26.715.2305.0 Installation: Microsoft Store Summary Launching Codex Desktop immediately causes extremely high CPU usage, even before opening any project. The CPU reaches 90–100% due to the combination of: ChatGPT / Codex processes Windows Defender (Antimalware Service Executable) WMI Provider Host (WmiPrvSE.exe) This significantly increases CPU temperature and system load. Expected Behavior Opening Codex Desktop without opening any project should result in minimal CPU usage (similar to VS Code extension). Actual Behavior Immediately after launching Codex Desktop: CPU usage jumps to 90–100%. Windows Defender starts consuming 20–40% CPU. WMI Provider Host also starts consuming 10–20% CPU. CPU temperature increases accordingly. This happens even while sitting on the Home screen without opening any workspace. Troubleshooting Performed I tested all of the following: ✅ Replaced CPU thermal paste. ✅ Verified CPU cooler installation. ✅ Tested CPU temperatures (hardware is working normally). ✅ Added Windows Defender exclusions for: Project folder C:\\Users\\\\AppData\\Local\\OpenAI ...\\Codex\\runtimes ✅ Restarted Windows. ✅ Disabled Windows Defender Real-time Protection. ✅ Tested without opening any project. ✅ Tested after removing NVIDIA RTX Voice. ✅ Checked WMI logs. ✅ Rebuilt Windows Performance Counters. ✅ Verified CPU is normal outside Codex. None of these resolved the issue. Important Observation When Real-time Protection is disabled: Windows Defender CPU usage disappears. Codex CPU usage increases instead. This suggests Defender is scanning Codex activity rather than being the original source. Comparison with VS Code Using the Codex extension inside VS Code: CPU usage remains around 40–70% No abnormal Defender behavior. Much lower overall system load. Only Codex Desktop reproduces this issue. WMI Activity Windows Event Viewer shows continuous WMI queries such as: Win32_Processor Win32_OperatingSystem Win32_PerfFormattedData_PerfProc_Process WMI Provider Host becomes active immediately after launching Codex Desktop. Additional Notes The issue occurs: without opening any project after reboot with Defender exclusions configured even on the Home screen This suggests the desktop application itself is triggering excessive background activity that causes Defender and WMI to become heavily active. Request Could the team investigate whether the current Windows Desktop build performs excessive background indexing, WMI queries, or runtime initialization that triggers Microsoft Defender? The behavior appears specific to Codex Desktop, since the VS Code extension does not reproduce the same level of CPU usage. ### What steps can reproduce the bug? High CPU Usage Triggered by Windows Defender & WMI When Launching Codex Desktop on Windows 10 Environment OS: Windows 10 Pro x64 CPU: Intel Core i5-10400F RAM: 16 GB GPU: NVIDIA GTX 1650 Codex Desktop Version: 26.715.2305.0 Installation: Microsoft Store Summary Launching Codex Desktop immediately causes extremely high CPU usage, even before opening any project. The CPU reaches 90–100% due to the combination of: ChatGPT / Codex processes Windows Defender (Antimalware Service Executable) WMI Provider Host (WmiPrvSE.exe) This significantly increases CPU temperature and system load. Expected Behavior Opening Codex Desktop without opening any project should result in minimal CPU usage (similar to VS Code extension). Actual Behavior Immediately after launching Codex Desktop: CPU usage jumps to 90–100%. Windows Defender starts consuming 20–40% CPU. WMI Provider Host also starts consuming 10–20% CPU. CPU temperature increases accordingly. This happens even while sitting on the Home screen without opening any workspace. Troubleshooting Performed I tested all of the following: ✅ Replaced CPU thermal paste. ✅ Verified CPU cooler installation. ✅ Tested CPU temperatures (hardware is working normally). ✅ Added Windows Defender exclusions for: Project folder C:\\Users\\\\AppData\\Local\\OpenAI ...\\Codex\\runtimes ✅ Restarted Windows. ✅ Disabled Windows Defender Real-time Protection. ✅ Tested without opening any project. ✅ Tested after removing NVIDIA RTX Voice. ✅ Checked WMI logs. ✅ Rebuilt Windows Performance Counters. ✅ Verified CPU is normal outside Codex. None of these resolved the issue. Important Observation When Real-time Protection is disabled: Windows Defender CPU usage disappears. Codex CPU usage increases instead. This suggests Defender is scanning Codex activity rather than being the original source. Comparison with VS Code Using the Codex extension inside VS Code: CPU usage remains around 40–70% No abnormal Defender behavior. Much lower overall system load. Only Codex Desktop reproduces this issue. WMI Activity Windows Event Viewer shows continuous WMI queries such as: Win32_Processor Win32_OperatingSystem Win32_PerfFormattedData_PerfProc_Process WMI Provider Host becomes active immediately after launching Codex Desktop. Additional Notes The issue occurs: without opening any project after reboot with Defender exclusions configured even on the Home screen This suggests the desktop application itself is triggering excessive background activity that causes Defender and WMI to become heavily active. Request Could the team investigate whether the current Windows Desktop build performs excessive background indexing, WMI queries, or runtime initialization that triggers Microsoft Defender? The behavior appears specific to Codex Desktop, since the VS Code extension does not reproduce the same level of CPU usage. ### What is the expected behavior? _No response_ ### Additional information High CPU Usage Triggered by Windows Defender & WMI When Launching Codex Desktop on Windows 10 Environment OS: Windows 10 Pro x64 CPU: Intel Core i5-10400F RAM: 16 GB GPU: NVIDIA GTX 1650 Codex Desktop Version: 26.715.2305.0 Installation: Microsoft Store Summary Launching Codex Desktop immediately causes extremely high CPU usage, even before opening any project. The CPU reaches 90–100% due to the combination of: ChatGPT / Codex processes Windows Defender (Antimalware Service Executable) WMI Provider Host (WmiPrvSE.exe) This significantly increases CPU temperature and system load. Expected Behavior Opening Codex Desktop without opening any project should result in minimal CPU usage (similar to VS Code extension). Actual Behavior Immediately after launching Codex Desktop: CPU usage jumps to 90–100%. Windows Defender starts consuming 20–40% CPU. WMI Provider Host also starts consuming 10–20% CPU. CPU temperature increases accordingly. This happens even while sitting on the Home screen without opening any workspace. Troubleshooting Performed I tested all of the following: ✅ Replaced CPU thermal paste. ✅ Verified CPU cooler installation. ✅ Tested CPU temperatures (hardware is working normally). ✅ Added Windows Defender exclusions for: Project folder C:\\Users\\\\AppData\\Local\\OpenAI ...\\Codex\\runtimes ✅ Restarted Windows. ✅ Disabled Windows Defender Real-time Protection. ✅ Tested without opening any project. ✅ Tested after removing NVIDIA RTX Voice. ✅ Checked WMI logs. ✅ Rebuilt Windows Performance Counters. ✅ Verified CPU is normal outside Codex. None of these resolved the issue. Important Observation When Real-time Protection is disabled: Windows Defender CPU usage disappears. Codex CPU usage increases instead. This suggests Defender is scanning Codex activity rather than being the original source. Comparison with VS Code Using the Codex extension inside VS Code: CPU usage remains around 40–70% No abnormal Defender behavior. Much lower overall system load. Only Codex Desktop reproduces this issue. WMI Activity Windows Event Viewer shows continuous WMI queries such as: Win32_Processor Win32_OperatingSystem Win32_PerfFormattedData_PerfProc_Process WMI Provider Host becomes active immediately after launching Codex Desktop. Additional Notes The issue occurs: without opening any project after reboot with Defender exclusions configured even on the Home screen This suggests the desktop application itself is triggering excessive background activity that causes Defender and WMI to become heavily active. Request Could the team investigate whether the current Windows Desktop build performs excessive background indexing, WMI queries, or runtime initialization that triggers Microsoft Defender? The behavior appears specific to Codex Desktop, since the VS Code extension does not reproduce the same level of CPU usage.", "url": "https://github.com/openai/codex/issues/33875", "createdAt": "2026-07-17T17:22:32Z", "updatedAt": "2026-08-13T10:48:48Z", "timestamp": "2026-08-13T10:48:48Z", "metrics": { "reactions": 19, "comments": 17 }, "labels": [ "bug", "windows-os", "app", "performance" ], "author": "ramisasa9080-blip", "state": "open", "assignees": [] }, { "id": "github:openai/codex:issue:33940", "source": "github", "group": "coding-agent-infrastructure", "project": "openai/codex", "kind": "issue", "title": "Windows: opening Codex causes sustained WMI Provider Host CPU usage and system stutter", "text": "## Summary Opening the Codex desktop app on Windows 11 causes sustained CPU usage from **WMI Provider Host** and **Windows Management Instrumentation**, even when Codex is idle and no project, workspace, or agent task has been opened. I rely heavily on Codex for day-to-day development and university work, so this regression has a direct impact on my ability to work. Please investigate and provide a fix or workaround. ## Environment - OS: Windows 11 - App: ChatGPT powered by Codex & OWL - Version: `26.715.31251` - Release date shown in the app: 18 July 2026 - Hardware: desktop PC ## Observed behavior 1. With Codex closed, total CPU usage returns to approximately 1–10%. 2. Opening Codex without opening a project or starting an agent causes total CPU usage to rise to approximately 30–50%. 3. During the spike, Task Manager repeatedly shows roughly: - `WMI Provider Host`: about 5–10% - `Windows Management Instrumentation`: about 4–8% - Microsoft Defender may also rise temporarily 4. The system intermittently stutters and the mouse can briefly stop responding. 5. Closing Codex causes WMI CPU usage to return near 0% almost immediately. 6. Reopening Codex reproduces the issue consistently. 7. ChatGPT Classic does not reproduce the issue. ## Troubleshooting already performed - Verified WMI repository: - `winmgmt /verifyrepository` - Result: `WMI repository is consistent` - Tested with Codex idle and no workspace open: issue still occurs. - Added the project folder to Microsoft Defender exclusions: no improvement. - Confirmed no full or quick Defender scan was running. - Stopped MSI Center services: no improvement. - Closed other foreground applications: issue remained tied to opening Codex. - ChatGPT Classic runs normally on the same machine. ## Relevant WMI event data The WMI Activity log contained repeated failed queries such as: ```text Operation = Start IWbemServices::ExecQuery - root\\cimv2 SELECT __PATH, ProcessId, CSName, Caption, SessionId, ThreadCount, WorkingSetSize, KernelModeTime, UserModeTime, ParentProcessId FROM Win32_Process ResultCode = 0x800706BE / 0x800706BA ``` Other WMI events included queries against DeviceGuard, BIOS, TPM, and processor information, but the repeated `Win32_Process` queries were the most prominent during the incident. ## Expected behavior Opening Codex while idle should not cause sustained WMI CPU usage, total CPU usage of 30–50%, or visible system stutter. ## Additional note This began immediately after updating to version `26.715.31251`. Screenshots of Task Manager and the WMI event output are available if needed.", "url": "https://github.com/openai/codex/issues/33940", "createdAt": "2026-07-18T02:19:30Z", "updatedAt": "2026-08-13T10:25:13Z", "timestamp": "2026-08-13T10:25:13Z", "metrics": { "reactions": 0, "comments": 4 }, "labels": [ "bug", "windows-os", "app", "performance" ], "author": "lordtd-hub", "state": "closed", "assignees": [] }, { "id": "github:openai/codex:issue:33967", "source": "github", "group": "coding-agent-infrastructure", "project": "openai/codex", "kind": "issue", "title": "ChatGPT for Windows cannot complete setup or enter limited-access mode", "text": "### What version of the Codex App are you using (From “About Codex” dialog)? 26.715.3651.0 ### What subscription do you have? ’m unable to use the ChatGPT desktop app on Windows because it is stuck on the “Complete Windows setup” screen. ### What platform is your computer? x64 ### What issue are you seeing? \"Image\" I’m unable to use the ChatGPT desktop app on Windows because it is stuck on the “Complete Windows setup” screen. Environment: - OS: Windows 10 Pro, version 22H2 / build 19045.6466 - ChatGPT Windows package: OpenAI.Codex - Current installed version: 26.715.3651.0 - Package name: OpenAI.Codex_26.715.3651.0_x64__2p2nqsd0c76g0 Problem: 1. The app opens to “Complete Windows setup.” 2. Clicking “Retry Windows setup” does not complete the setup. 3. The UAC/administrator setup flow does not resolve the issue. 4. Clicking “Continue with limited access” also does not enter the main ChatGPT interface; the app remains unusable on the setup screen. 5. I uninstalled and reinstalled the app, and the issue persists even with the newer installed version. Relevant diagnostic information: - The app package status is reported as Ok. - Windows Defender Firewall and Base Filtering Engine services are running. - An existing sandbox setup log contains this error: text helper_firewall_rule_create_or_add_failed: SetRemotePorts failed: HRESULT(0x80070057) / The parameter is incorrect This appears to occur while the app attempts to configure the Windows sandbox/firewall rules required for local agent functionality. Expected behavior: - The setup should complete successfully after administrator approval; or - “Continue with limited access” should open the normal ChatGPT interface without requiring the local sandbox. Actual behavior: - Neither path allows access to the ChatGPT app. I have attached a screenshot of the setup screen. Please advise whether this is a known Windows 10 compatibility issue or provide a supported repair/workaround that does not require deleting local user data. ### What steps can reproduce the bug? ChatGPT for Windows cannot complete setup or enter limited-access mode ### What is the expected behavior? _No response_ ### Additional information _No response_", "url": "https://github.com/openai/codex/issues/33967", "createdAt": "2026-07-18T07:12:26Z", "updatedAt": "2026-08-12T21:54:50Z", "timestamp": "2026-08-12T21:54:50Z", "metrics": { "reactions": 0, "comments": 12 }, "labels": [ "bug", "windows-os", "sandbox", "app" ], "author": "YUWEN", "state": "open", "assignees": [] }, { "id": "github:openai/codex:issue:33986", "source": "github", "group": "coding-agent-infrastructure", "project": "openai/codex", "kind": "issue", "title": "unified-exec exec_command: Bash PreToolUse tool_input drops the honored per-call workdir, so hooks cannot attribute the execution root", "text": "### What version of Codex are you using? `codex-cli 0.144.5` (Homebrew, macOS arm64). The behavior is unchanged on current `main` as of 2026-07-18. ### What platform is your computer? macOS (Apple Silicon). The projection lives in `codex-rs/core`, so this is platform-independent. ### What issue are you seeing? When the model calls unified-exec `exec_command` with a per-call `workdir`, the Bash `PreToolUse` hook payload drops that field, even though execution honors it. In `codex-rs/core/src/tools/handlers/unified_exec/exec_command.rs`, `ExecCommandHandler::pre_tool_use_payload` parses `ExecCommandArgs` and projects only the command: ```rust parse_arguments::(arguments) .ok() .map(|args| PreToolUsePayload { tool_name: HookToolName::bash(), tool_input: serde_json::json!({ \"command\": args.cmd }), }) ``` while `handle_call` in the same handler separately parses `ExecCommandEnvironmentArgs`, resolves `workdir` against the selected environment's cwd, and executes there: ```rust let cwd = environment_args .workdir .as_deref() .filter(|workdir| !workdir.is_empty()) .map_or_else( || Ok(native_environment_cwd.clone()), |workdir| native_environment_cwd.join(workdir), ) ``` So two `exec_command` calls with identical `cmd` but different `workdir` values deliver byte-identical `tool_input` to the hook while running in different directories. The hook envelope's top-level `cwd` is the session working directory (per the Hooks docs), not the per-call execution root, so a hook cannot reconstruct where the command will actually run. The command-only projection is regression-locked by `exec_command_pre_tool_use_payload_uses_raw_command` in `codex-rs/core/src/tools/handlers/unified_exec_tests.rs`. **Authorization impact:** in multi-worktree repositories where a `PreToolUse` hook enforces \"mutations happen only in the assigned task worktree\", a relative mutation (e.g. `git add .`, a formatter `-w` run) with `workdir=` is observationally identical to the same command running in the primary checkout or a foreign directory. A strict hook must fail closed and deny legitimate worktree work; a permissive hook silently misattributes the execution root and fails open. I verified this with paired read-only probes on 0.144.5: two `exec_command` calls, both `cmd: \"pwd\"`, one with the task-worktree `workdir` and one with the primary-checkout `workdir`. Both hook deliveries carried `tool_input` whose SHA-256 matches canonical `{\"command\":\"pwd\"}` exactly (proving no other distinguishing field was present), while the captured outputs showed the two distinct physical directories. ### What steps can reproduce the bug? 1. Configure a project `PreToolUse` hook for `bash` that logs the raw `tool_input` it receives. 2. In a session, have the model run `exec_command` with `cmd: \"pwd\"` and no `workdir`, then again with an explicit `workdir` pointing at a subdirectory or another worktree. 3. Observe that both hook deliveries carry identical `tool_input` (`{\"command\":\"pwd\"}`) and identical top-level `cwd`, while the tool outputs show different directories. ### What is the expected behavior? Bash `PreToolUse` `tool_input` should carry a trustworthy per-call workdir. Three properties matter for authorization-grade consumers: 1. **Explicit vs absent stays distinguishable.** Include `workdir` only when the call supplied a non-empty one; omit it otherwise, so hooks can tell \"no per-call workdir — environment cwd applies\" apart from \"explicit workdir\". 2. **Raw vs resolved semantics are defined.** The raw requested `workdir` may be relative and is resolved against the *selected environment's* cwd — which is not necessarily the session `cwd` the hook envelope carries. Exposing the effective resolved cwd (the value `handle_call` computes) is the stronger contract; if only the raw field is exposed, please document which base it resolves against. 3. **Read-only is sufficient.** Hook input rewriting currently only rewrites `command` (`with_updated_hook_input`), so adding the field does not need to grant hooks a workdir-rewrite capability. Minimal seam sketch for the raw-field variant (the resolved-cwd variant would instead thread the selected environment cwd into the payload — either works for consumers as long as the semantics are documented): ```rust fn pre_tool_use_payload(&self, invocation: &ToolInvocation) -> Option { let ToolPayload::Function { arguments } = &invocation.payload else { return None; }; let args = parse_arguments::(arguments).ok()?; let workdir = parse_arguments::(arguments) .ok() .and_then(|env| env.workdir) .filter(|workdir| !workdir.is_empty()); let mut tool_input = serde_json::json!({ \"command\": args.cmd }); if let Some(workdir) = workdir { tool_input[\"workdir\"] = serde_json::Value::String(workdir); } Some(PreToolUsePayload { tool_name: HookToolName::bash(), tool_input, }) } ``` plus updating `exec_command_pre_tool_use_payload_uses_raw_command` and adding a case asserting the field is omitted when no `workdir` was supplied. ### Related #20879 reports the same class of gap for native `apply_patch` (no per-call workdir context for hooks). This issue is specifically about unified-exec `exec_command`, where a per-call `workdir` already exists and is honored by execution but is dropped from the hook projection.", "url": "https://github.com/openai/codex/issues/33986", "timestamp": "2026-08-12T12:54:19Z", "metrics": { "reactions": 0, "comments": 2 }, "labels": [ "bug", "exec", "CLI", "hooks" ], "author": "duhlink", "assignees": [], "change": "new" }, { "id": "github:openai/codex:issue:34013", "source": "github", "group": "coding-agent-infrastructure", "project": "openai/codex", "kind": "issue", "title": "Windows sandbox helpers race while updating deny_read_acl_state.json", "text": "## What version of Codex CLI is running? `codex-cli 0.144.5` > **Update (2026-08-13):** The transaction-lock root cause remains present in current `main`, but later Windows validation found that the linked historical candidate's `NamedTempFile::persist` step is not the final replacement primitive needed for an existing/open destination. The mutex design remains valid; the persistence portion is superseded by the `ReplaceFileW`/`MoveFileExW` design and validation described in [this follow-up](https://github.com/openai/codex/issues/34013#issuecomment-5271090410). The failure was captured from a local build based on the exact `rust-v0.144.5` source. Its unrelated context-window changes did not modify `codex-rs/windows-sandbox-rs`. The same unlocked state implementation remains in `main` at `56395bdda`. ## What subscription do you have? Pro ## Which model were you using? `gpt-5.6-sol` ## What platform is your computer? `Microsoft Windows NT 10.0.19045.0 x64` ## What terminal emulator and version are you using (if applicable)? Windows Terminal `1.24.11321.0` with PowerShell `7.6.3` (`Core`, x64). No terminal multiplexer. ## Codex doctor report Relevant results from `codex doctor --json` are summarized below; unrelated entries are omitted. ```json { \"schemaVersion\": 1, \"overallStatus\": \"warning\", \"codexVersion\": \"0.144.5\", \"checks\": { \"system.environment\": { \"status\": \"ok\", \"os\": \"Windows 10 Pro 10.0.19045, 64-bit\" }, \"sandbox.helpers\": { \"status\": \"ok\", \"approvalPolicy\": \"OnRequest\", \"filesystemSandbox\": \"restricted\", \"networkSandbox\": \"restricted\" }, \"state.paths\": { \"status\": \"ok\", \"databaseIntegrity\": \"state, log, goals, and memories checks passed\" }, \"network.provider_reachability\": { \"status\": \"ok\" }, \"network.websocket_reachability\": { \"status\": \"ok\" } } } ``` The overall warning came from 19 old rollout files that contained no parseable rollout items. It is unrelated to the sandbox state-file race. ## What issue are you seeing? When several sandboxed tool calls start in parallel on Windows, their `codex-windows-sandbox-setup.exe` processes concurrently update the shared file: ```text %USERPROFILE%\\.codex\\.sandbox\\deny_read_acl_state.json ``` In the captured run, six setup helpers started within a few milliseconds. Two failed with: ```text setup error: apply deny-read ACLs Caused by: 0: parse deny-read ACL state \\.sandbox\\deny_read_acl_state.json 1: EOF while parsing a value at line 1 column 0 ``` The affected commands failed with `helper_unknown_error: apply deny-read ACLs`. Retrying the same command by itself succeeded. The root cause is in `codex-rs/windows-sandbox-rs/src/deny_read_state.rs`: 1. `sync_persistent_deny_read_acls()` loads the shared state. 2. It applies new ACLs and revokes stale ACLs. 3. `store_state()` calls `std::fs::write()` with no inter-process lock. 4. `std::fs::write()` truncates the destination before writing the new JSON. Another helper can read during that truncate/write interval and receive empty bytes, producing the EOF parse error. Even when every read parses successfully, two helpers updating different principals can both load the same old state and overwrite one another, losing one update. ## What steps can reproduce the bug? Runtime reproduction: 1. Use the Windows workspace-write sandbox. 2. Start multiple filesystem tool calls in parallel so several setup helpers run at the same time. 3. Inspect the failed tool result and the daily file under `\\.sandbox\\sandbox.YYYY-MM-DD.log`. A deterministic state-layer regression test also reproduces the lost-update form without changing real ACLs: 1. Synchronize eight state updates so they all load the same initial JSON. 2. Have every update add a distinct principal and then store the result. 3. On unmodified `main`, the final state contains 1 principal instead of 8. The candidate also launches six child test processes against one state file to verify the fix across real process boundaries. No thread ID is required; this occurs in the local Windows helper before the sandboxed command starts. ## What is the expected behavior? Concurrent setup helpers should serialize the full persistent state transaction. Every helper should see complete JSON, updates for different principals should not be lost, and parallel shell/file operations should not fail during sandbox setup. ## Additional information Historical candidate branch: https://github.com/starriet9/codex/tree/fix/windows-sandbox-deny-read-state-race Candidate commit: https://github.com/starriet9/codex/commit/0280e7b8ed1b58f95f2d4da732c601bbf02b7310 The historical candidate: - holds a Windows named mutex across the complete `load -> ACL apply/revoke -> store` transaction - treats an abandoned mutex as acquired, allowing recovery after a process exits - writes the JSON to a temporary file in the same directory, flushes it, and atomically replaces the previous state - adds thread-level and child-process concurrency regression tests Validation on Windows: ```text Original synchronized test: final principal count 1, expected 8 Patched thread test: 8 of 8 principals preserved Patched process test: 6 of 6 principals preserved cargo fmt -p codex-windows-sandbox -- --check: passed cargo clippy --offline -p codex-windows-sandbox --all-targets -- -D warnings: passed cargo build --offline --release -p codex-windows-sandbox --bins: passed ``` The process regression test uses actual child processes and a Windows kernel mutex without changing real filesystem ACLs. I did not run a full parallel setup-helper stress against the machine's live sandbox accounts, ACLs, firewall, and Windows Filtering Platform (WFP) state because that would mutate system security configuration. Related issue #30251 reports a state file that is already malformed or filled with NUL bytes and has a candidate that treats malformed JSON as empty state and uses atomic replacement. Atomic replacement prevents readers from observing a partially written file, but it does not serialize the complete read-modify-write transaction: two helpers can still load the same old state and atomically replace it with different updates, losing one update. The candidate in this report adds that missing transaction lock; it intentionally does not recover a state file that was already corrupt before startup. Related issue #30540 likewise covers recovery after the JSON has already been corrupted, such as after a crash or power interruption. This report is distinct: it identifies a live concurrency path that can corrupt or lose the state during normal parallel tool execution. I have not opened a pull request because `docs/contributing.md` says external pull requests are by invitation only. Do not treat the linked historical branch as a final current-main candidate; the follow-up above records the corrected Windows replacement design that should be used when refreshing it.", "url": "https://github.com/openai/codex/issues/34013", "createdAt": "2026-07-18T13:09:35Z", "updatedAt": "2026-08-13T06:22:47Z", "timestamp": "2026-08-13T06:22:47Z", "metrics": { "reactions": 0, "comments": 1 }, "labels": [ "bug", "windows-os", "sandbox", "CLI" ], "author": "starriet9", "state": "open", "assignees": [] }, { "id": "github:openai/codex:issue:34053", "source": "github", "group": "coding-agent-infrastructure", "project": "openai/codex", "kind": "issue", "title": "Allow configuring retry policy and honor `Retry-After` for TPM rate limits in Codex", "text": "### What variant of Codex are you using? IDE Extension ### What feature would you like to see? ## Summary When Codex encounters an OpenAI TPM (Tokens Per Minute) rate limit during a long-running streaming task, it performs a fixed number of reconnect attempts (currently 5) and then terminates the agent. For large repositories and long-running coding sessions, this frequently aborts otherwise recoverable tasks. It would be very helpful if Codex exposed a configurable retry policy and honored the server's `Retry-After` guidance instead of terminating after a fixed reconnect count. --- ## Current behavior Example: ``` stream disconnected before completion: Rate limit reached for gpt-5.6-sol Limit: 500000 TPM Used: 452786 Requested: 135822 Please try again in 10.632s ``` Codex then shows: ``` Reconnecting 1/5 Reconnecting 2/5 ... Reconnecting 5/5 ``` After the fifth reconnect, the agent stops and requires manual intervention. --- ## Expected behavior Instead of aborting after a fixed number of reconnects, Codex should continue retrying until the request can be admitted, or until a configurable timeout/retry budget is reached. Ideally: - Honor the server's `Retry-After` (or equivalent) delay when provided. - Fall back to exponential backoff if no retry delay is available. - Allow users to configure retry behavior. Example configuration: ```toml [retry_policy] max_retries = 50 max_retry_duration = \"30m\" retry_delay_seconds = 30 honor_retry_after = true ``` or simply: ```toml retry_policy = \"adaptive\" ``` --- ## Why this matters Large repositories and long conversations can easily produce requests exceeding 100k tokens. Example: ``` Limit: 500000 TPM Used: 451244 Requested: 137781 Please try again in 10.683s ``` These are usually temporary rolling-window TPM limits. The agent already knows when it can retry, but instead exhausts its reconnect budget and exits. Keeping the agent alive would allow long-running investigations and refactoring sessions to continue automatically without user intervention. --- ## Environment - Codex CLI: 0.144.6 - VS Code Codex extension - OpenAI API key authentication - Model: gpt-5.6-sol - Ubuntu 24.04 - Large repository (~130k token requests) --- ## Additional notes I investigated the configuration options and confirmed that: - `request_max_retries` / `stream_max_retries` cannot be applied to the built-in `openai` provider. - There does not appear to be a supported way to configure reconnect count or reconnect delay for the built-in provider. - The server already returns a retry delay (`Please try again in X seconds`), which seems like a good candidate for adaptive retry behavior. This would significantly improve reliability for users working with large repositories and long-running agent sessions. ### Additional information I spent some time investigating this before opening the feature request. Things I verified: - Codex CLI 0.144.6 (latest available) - VS Code Codex extension - OpenAI API key authentication - `codex doctor` reports a healthy installation - Configuration loads successfully - I confirmed that `request_max_retries` and `stream_max_retries` cannot be configured for the built-in `openai` provider because it is reserved. The server consistently returns messages such as: - Limit: 500000 TPM - Used: 451244 - Requested: 137781 - Please try again in 10.683s However, Codex still performs only five reconnect attempts before terminating the session. I'm not requesting a way to bypass rate limits. I want Codex to remain alive and automatically retry after the recommended delay (or another configurable delay) until the rolling TPM window has enough capacity again. This is particularly valuable for long-running investigations on large repositories, where manually restarting the agent interrupts workflow and loses momentum.", "url": "https://github.com/openai/codex/issues/34053", "createdAt": "2026-07-18T18:55:36Z", "updatedAt": "2026-08-13T06:43:58Z", "timestamp": "2026-08-13T06:43:58Z", "metrics": { "reactions": 2, "comments": 2 }, "labels": [ "enhancement", "extension", "rate-limits", "connectivity", "config" ], "author": "pip-install-skills", "state": "open", "assignees": [] }, { "id": "github:openai/codex:issue:34094", "source": "github", "group": "coding-agent-infrastructure", "project": "openai/codex", "kind": "issue", "title": "TUI finalized assistant messages can render blank Markdown lines as two viewport rows", "text": " ## What version of Codex CLI is running? `codex-cli 0.144.5` installed with the standalone Windows installer. The runtime reproduction was captured on this version; the source-level regression is also present in the current `rust-v0.144.6` release tag. ## What subscription do you have? Pro ## Which model were you using? `gpt-5.6-sol` ## What platform is your computer? `Microsoft Windows NT 10.0.19045.0 x64` (Windows 10 Pro 22H2) ## What terminal emulator and version are you using (if applicable)? Windows Terminal `1.24.11321.0` with PowerShell `7.6.3` (`Core`, x64). No terminal multiplexer. ## Codex doctor report Relevant results from `codex doctor --json` are summarized below; unrelated entries are omitted. ```json { \"schemaVersion\": 1, \"codexVersion\": \"0.144.5\", \"checks\": { \"installation\": { \"status\": \"ok\", \"summary\": \"installation looks consistent\", \"installContext\": \"standalone (windows)\" }, \"runtime.provenance\": { \"status\": \"ok\", \"summary\": \"running standalone on windows-x86_64\", \"platform\": \"windows-x86_64\", \"version\": \"0.144.5\" }, \"system.environment\": { \"status\": \"ok\", \"os\": \"Windows 10.0.19045 (Windows 10 Pro) [64-bit]\", \"osLanguage\": \"ko-KR\" }, \"terminal.env\": { \"status\": \"ok\", \"terminal\": \"Windows Terminal\", \"WT_SESSION\": \"present\", \"consoleInputCodePage\": \"949\", \"consoleOutputCodePage\": \"65001\" } } } ``` ## What issue are you seeing? After an assistant response is finalized, an intended blank Markdown line can occupy two terminal viewport rows instead of one. I notice this most clearly after pressing `Ctrl+T` to open the transcript overlay: spacing between finalized paragraphs, lists, or tables becomes visibly larger than the source Markdown requires. For the logical message `first\\n\\nsecond`, the finalized `AgentMarkdownCell` produces a whitespace-only line containing two spaces instead of a structurally empty line: ```text actual: [\"• first\", \" \", \" second\"] expected: [\"• first\", \"\", \" second\"] ``` Ratatui can measure that whitespace-only line as two viewport rows. PR #26636 fixed the same row-height mechanism for the transient `StreamingAgentTailCell`, but the finalized `AgentMarkdownCell` still returns the result of `prefix_hyperlink_lines(...)` without applying that normalization. ## What steps can reproduce the bug? 1. Start Codex CLI in Windows Terminal. 2. Ask for a response containing paragraphs, lists, or tables separated by single blank Markdown lines. 3. Wait for the response to finish so the assistant message is finalized. 4. Press `Ctrl+T` to open the transcript overlay. 5. Observe that some intended single blank lines occupy two viewport rows. The source-level reproduction is deterministic: ```rust let cell = AgentMarkdownCell::new(\"first\\n\\nsecond\".to_string(), &test_cwd()); let lines = cell.display_lines(/*width*/ 80); insta::assert_snapshot!(render_lines(&lines).join(\"\\n\"), @\" • first second \"); assert_eq!(cell.desired_transcript_height(/*width*/ 80), 3); ``` On unmodified `main` at `b8b61bc69`, the snapshot fails because the actual blank line is `\" \"`. With the candidate change, the snapshot and height assertion both pass. ## What is the expected behavior? One blank Markdown line should remain structurally empty and occupy exactly one viewport row in both streaming and finalized/transcript rendering. Opening or closing the transcript overlay should not change the vertical spacing of a finalized assistant message. ## Additional information The latest stable release during validation was `0.144.6`. Its `rust-v0.144.6` source tag still returns `prefix_hyperlink_lines(...)` directly from `AgentMarkdownCell::display_hyperlink_lines`, so the finalized path does not contain the normalization already used by the streaming path. Related but distinct prior fix: https://github.com/openai/codex/pull/26636 Candidate branch: https://github.com/starriet9/codex/tree/fix/transcript-finalized-blank-rows Candidate commit: https://github.com/starriet9/codex/commit/b445b9d6082661a3eb97a42be317455f92cb3eae The candidate extracts the existing whitespace-only `HyperlinkLine` normalization into a helper and applies it after prefixing in both `StreamingAgentTailCell` and finalized `AgentMarkdownCell`. Nonblank prefixes and styles are unchanged, and impossible hyperlink metadata is cleared only for whitespace-only lines. Validation on Windows: ```text Unmodified main plus the regression test: failed; actual blank line was \" \" Candidate targeted regression test: passed history_cell::tests: 107 passed, 0 failed, 2 ignored required_stream_reflow_during_capped_initial_replay*: 2 passed, 0 failed cargo fmt -p codex-tui -- --check: passed cargo clippy --offline -p codex-tui --all-targets -- -D warnings: passed cargo build --offline -p codex-cli: passed ``` I have not opened a pull request because `docs/contributing.md` says external pull requests are by invitation only. The focused branch is ready if maintainers want a PR.", "url": "https://github.com/openai/codex/issues/34094", "createdAt": "2026-07-19T01:23:26Z", "updatedAt": "2026-08-13T06:22:48Z", "timestamp": "2026-08-13T06:22:48Z", "metrics": { "reactions": 0, "comments": 1 }, "labels": [ "bug", "windows-os", "TUI", "CLI" ], "author": "starriet9", "state": "closed", "assignees": [] }, { "id": "github:openai/codex:issue:34114", "source": "github", "group": "coding-agent-infrastructure", "project": "openai/codex", "kind": "issue", "title": "Random Chinese text occasionally appears in scheduled heartbeat messages", "text": "### What version of the Codex App are you using (From “About Codex” dialog)? 26.715.31925 ### What subscription do you have? Pro 20x ### What platform is your computer? Darwin 25.5.0 arm64 arm ### What issue are you seeing? ## Description I’m using a scheduled task with a heartbeat in the Codex app. Occasionally, unrelated Chinese text is appended to the heartbeat output after the automation ID. Examples: ```text monitor-cc-safety-net-false-positives 天天啪 ``` ```text monitor-cc-safety-net-false-positives 俺也去 ``` The Chinese text was not included in my task prompt and does not appear to be related to the task, its output, or my project. The issue occurs intermittently rather than on every scheduled run. **Feedback ID:** `019f5e6a-cc1e-76a2-aeb3-3b26cf26d1de` \"Image\" ### What steps can reproduce the bug? ## Steps to reproduce 1. Create a recurring scheduled task in the Codex app. 2. Configure the task to send heartbeat updates. 3. Let the task run across multiple scheduled executions. 4. Check the heartbeat messages. 5. Occasionally, unrelated Chinese text appears after the automation ID. ### What is the expected behavior? ## Expected behavior The heartbeat message should contain only the expected heartbeat metadata and task output. ### Additional information ## Additional information - Model: `GPT 5.6 Terra High` - Automation ID: `monitor-cc-safety-net-false-positives` - The scheduled task otherwise appears to run normally. - The issue has occurred more than once with different Chinese text. - A screenshot showing multiple occurrences is attached. - I also submitted this bug through the Codex app’s feedback feature.", "url": "https://github.com/openai/codex/issues/34114", "createdAt": "2026-07-19T04:19:19Z", "updatedAt": "2026-08-12T20:40:46Z", "timestamp": "2026-08-12T20:40:46Z", "metrics": { "reactions": 0, "comments": 3 }, "labels": [ "bug", "app", "automations" ], "author": "kenryu42", "state": "open", "assignees": [] }, { "id": "github:openai/codex:issue:34260", "source": "github", "group": "coding-agent-infrastructure", "project": "openai/codex", "kind": "issue", "title": "Windows Desktop: unbounded taskkill.exe/conhost.exe cleanup storm exhausts WMI", "text": "## Summary Codex Desktop on Windows can enter an unbounded process-cleanup loop where hundreds of `taskkill.exe` processes remain alive, each with a corresponding `conhost.exe`. The accumulated `taskkill` instances repeatedly query `Win32_Process`, exhaust the WMI provider quota, and make the entire Windows UI sluggish or unable to launch new processes. This is related to openai/codex#17229 and openai/codex#21957, but the leaking processes in this case are `taskkill.exe` themselves rather than only `git.exe`/`conhost.exe` or leaked stdout. ## Environment * Codex Desktop: `26.715.4045.0` * OS: Windows 25H2 x64, build `26200.8875` * RAM: 32 GB * Installation: Microsoft Store/MSIX package `OpenAI.Codex_26.715.4045.0_x64__2p2nqsd0c76g0` ## Observed behavior During normal local-agent use involving shell commands, cancellations, and command timeouts, process counts grew continuously. Peak measurements: * `taskkill.exe`: 457 processes * `conhost.exe`: 473 processes * total processes: 1,388 * total threads: over 14,000 * total handles: over 350,000 * WMI provider private memory: 720.5 MB All sampled `taskkill.exe` instances had the Codex Desktop main process (`ChatGPT.exe` inside the `OpenAI.Codex` package) as their parent. Most excess `conhost.exe` instances were children of those `taskkill.exe` processes. Windows Event Viewer recorded: * WMI event 5612: `PrivatePageCount` exceeded its 512 MB quota. * WMI event 5612: `ThreadCount` exceeded its 256-thread quota. * WMI Activity event 5858: repeated `Win32_Process` queries failed with `0x80041006` and `0x80041033`. * `taskkill.exe` crashed with exception `0xc0000005` (Application Error event 1000 / Windows Error Reporting event 1001). Killing the accumulated `taskkill.exe` processes immediately reduced the total process count from 1,388 to about 565, and WMI private memory fell from 720.5 MB to about 104 MB. However, while the original Codex process remained running, `taskkill.exe` counts grew again from 156 to 320 in 20 seconds. Fully restarting/reinstalling Codex cleared the bad state. With the same app version reinstalled, the stable baseline was: * `taskkill.exe`: 0 * `conhost.exe`: 12 * total processes: about 390 * WMI: 139 MB private memory / 54 threads Because the reinstalled version is identical, this appears to clear the accumulated state rather than fix the underlying bug. ## Relevant packaged-app implementation Inspection of the installed `app.asar` shows that the Windows process-tree cleanup path invokes approximately: ```js execFile(taskkill.exe, [\"/pid\", pid, \"/t\", \"/f\"], { windowsHide: true, }); ``` The call does not appear to set a timeout. Cleanup is deduplicated per execution object, but there is no apparent global concurrency limit, backoff, or circuit breaker across multiple local executions. If `taskkill.exe` hangs because process enumeration/WMI is unhealthy, later cleanups can start additional `taskkill.exe` instances indefinitely. ## Steps that may reproduce 1. Open Codex Desktop on Windows and a local repository. 2. Run multiple local shell operations, including operations that time out or are cancelled. 3. Observe `taskkill.exe` and `conhost.exe` in Task Manager or Process Explorer. 4. If WMI/process enumeration becomes slow, observe whether `taskkill.exe` instances remain alive and increase continuously. 5. Keep the app open and observe WMI event 5858 failures and growing process/thread/handle counts. The trigger is intermittent; the unbounded accumulation after the first stuck cleanup is the main defect. ## Expected behavior * A process-tree cleanup should complete or time out within a bounded period. * Codex should not run hundreds of concurrent `taskkill.exe` cleanup processes. * Repeated cleanup failures should activate backoff/circuit breaking and surface one actionable error to the user. * Failure of WMI/process enumeration should not cause a system-wide process storm. ## Suggested fixes 1. Add a timeout to the `taskkill.exe` invocation and forcibly terminate a stuck cleanup helper. 2. Add a process-wide single-flight or small concurrency limit for Windows tree cleanup. 3. Add exponential backoff/circuit breaking after repeated cleanup failures. 4. Prefer Windows Job Objects or direct Win32 process-tree termination instead of spawning `taskkill.exe` for every cleanup. 5. Log the target PID, duration, exit status, and number of concurrent cleanup operations.", "url": "https://github.com/openai/codex/issues/34260", "createdAt": "2026-07-20T03:58:11Z", "updatedAt": "2026-08-13T03:42:51Z", "timestamp": "2026-08-13T03:42:51Z", "metrics": { "reactions": 13, "comments": 34 }, "labels": [ "bug", "windows-os", "tool-calls", "app", "performance", "Papercuts 2026" ], "author": "RocStone", "state": "open", "assignees": [] }, { "id": "github:openai/codex:issue:34268", "source": "github", "group": "coding-agent-infrastructure", "project": "openai/codex", "kind": "issue", "title": "Multi-agent V2 full-history forks duplicate historical compaction snapshots and inline images, causing >100 GiB session storage growth", "text": "### What issue are you seeing? A long-running Codex Desktop conversation using Ultra reasoning and multi-agent V2 produced approximately 110 GiB of local session data under `$CODEX_HOME/sessions`. The growth appears multiplicative rather than being caused by subagents producing unusually large outputs: 1. Context compaction persists `Compacted` rollout records containing a complete `replacement_history`. 2. These replacement histories can contain inline base64-encoded screenshots. 3. Older compaction records remain in the append-only parent rollout. 4. A full-history subagent fork loads the parent’s persisted rollout items. 5. Those inherited items—including all historical compaction snapshots—are serialized into the child rollout. 6. Ultra reasoning proactively creates many subagents, multiplying the retained history across many files. Observed impact from one session tree: | Measurement | Result | |---|---:| | Total rollout files | 300 | | Total reported size | approximately 110.09 GiB | | Subagent rollout files | 294 | | Size attributed to subagent rollouts | approximately 106.56 GiB | | Files sharing the same root session ID | 295 | | Files at least 1 GB | 51 | | Files at least 500 MB | 86 | | Files at least 100 MB | 155 | Of those files, 159 were recorded by `0.145.0-alpha.18` with `multi_agent_version: \"v2\"` and accounted for approximately 88.18 GiB. Many individual subagent rollouts were between 1.3 GB and 1.9 GB. A representative completed child rollout was `1,706,557,797` bytes and contained 23,564 JSONL records. Its composition was: - 141 `compacted` records - Approximately 1.55 GiB in `compacted` records - 97.6% of the entire file attributable to `compacted` records - 125 individual JSONL records larger than 10 MB - Largest JSONL record approximately 12.93 MiB One inspected `replacement_history` contained: - 118 history items - 19 `input_image` entries - 13,316,621 characters of inline `data:image/png;base64,...` data - Approximately 197,716 characters of input text The child files are not small records that merely reference their parent. A representative child begins with its own `session_meta`, followed by a copy of the parent’s original `session_meta` and inherited parent events. Sampled parent payloads were identical, while outer timestamps were rewritten to the child creation time and some response items received new IDs. The files have separate inodes and link counts of `1`, and their allocated sizes are close to their logical sizes. This appears to be independently serialized history rather than sparse files or parent references. This can consume enough storage to exhaust a local disk during a single long-running Ultra session. ### What steps can reproduce the bug? The severity depends on having a sufficiently large parent history, multiple compactions, inline images, and multiple full-history forks. 1. Start a persisted local Codex thread using Codex Desktop or another local surface backed by the shared Codex runtime. 2. Use the same thread for an extended period. 3. Add several screenshots or other image inputs to the conversation. 4. Continue the conversation long enough to trigger multiple context compactions. 5. Select Ultra reasoning with multi-agent V2 enabled. 6. Give Codex work that causes it to proactively spawn multiple subagents. 7. Allow the generated `spawn_agent` calls to omit `fork_turns`. In multi-agent V2, the omitted value defaults to `\"all\"`. 8. Inspect the newly created child rollouts under `$CODEX_HOME/sessions`. 9. Compare their sizes and initial JSONL records with the parent rollout. 10. Repeat with additional subagents and observe that each full-history child can approach the persisted historical size of the parent before doing significant child-specific work. Example read-only inspection commands: du -sh \"$CODEX_HOME/sessions\" find \"$CODEX_HOME/sessions\" -type f -name '*.jsonl' -print0 \\ | xargs -0 stat -f '%z %N' \\ | sort -nr \\ | head -50 For a suspected child file: head -n 1 \"$CHILD_ROLLOUT\" \\ | jq '.payload | { id, session_id, thread_source, forked_from_id, parent_thread_id, multi_agent_version, source }' The child metadata should identify it as a subagent and point to the parent through `parent_thread_id` and/or `forked_from_id`. Inspecting the first several records should show the child’s new `session_meta` followed by inherited parent rollout records. The problem becomes increasingly visible as these factors increase: - Number of retained compaction records - Number and size of inline images - Length of the parent thread - Number of spawned subagents - Use of full-history/default `fork_turns=\"all\"` behavior ### What is the expected behavior? Spawning subagents should not cause local persisted session storage to grow in proportion to the parent’s complete append-only rollout history for every child, particularly when the history contains multiple historical compaction snapshots representing earlier versions of substantially the same model context. A newly spawned child should not routinely approach 1–2 GB before performing meaningful child-specific work. Disk growth should remain bounded enough that proactive multi-agent behavior cannot unexpectedly create more than 100 GiB of local session data from one conversation tree. This expectation applies regardless of whether the triggering surface is Codex Desktop, the CLI, or `codex exec`, since the relevant multi-agent and rollout-persistence behavior appears to be shared. ### Additional information Environment and metadata from the affected session: - Platform: macOS - Surface: Codex Desktop - Reasoning mode: Ultra - Root metadata: - `originator: \"Codex Desktop\"` - `source: \"vscode\"` - `history_mode: \"legacy\"` - Child metadata: - `thread_source: \"subagent\"` - `multi_agent_version: \"v2\"` - Codex versions present: - `0.144.2` - `0.144.5` - `0.145.0-alpha.18` Relevant source locations: - `codex-rs/core/src/session/multi_agents.rs` - `effective_multi_agent_mode` maps Ultra reasoning to proactive multi-agent behavior. - The behavior applies to `SessionSource::Cli`, `SessionSource::VSCode`, `SessionSource::Exec`, and other sources. - `codex-rs/core/src/tools/handlers/multi_agents_v2/spawn.rs` - `SpawnAgentArgs::fork_mode` defaults omitted or empty `fork_turns` to `\"all\"`. - `\"all\"` becomes `SpawnAgentForkMode::FullHistory`. - `codex-rs/core/src/agent/control/spawn.rs` - `AgentControl::spawn_forked_thread` flushes the parent and reads the stored thread with `include_history: true`. - It uses `parent_history.items` as the forked rollout items. - The fork filter retains `RolloutItem::Compacted`. - The inspected `Compacted` records contain almost all of the affected bytes. - `codex-rs/core/src/session/mod.rs` - The `InitialHistory::Forked` branch in `record_initial_history` persists the inherited rollout items. - The code comment says: `If persisting, persist all rollout items as-is (the store filters).` - `codex-rs/core/src/compact.rs` - Compaction creates a `CompactedItem` with `replacement_history: Some(new_history.clone())`. - `codex-rs/core/src/session/mod.rs` - `replace_compacted_history` also persists a `CompactedItem` containing a cloned replacement history. - `codex-rs/rollout/src/recorder.rs` - `JsonlWriter::write_rollout_item` assigns a new timestamp, serializes the item with `serde_json::to_string`, and writes it to the child JSONL. - `codex-rs/app-server/README.md` - `thread/fork` is documented as creating a new thread by copying stored history. Questions that may help confirm whether the observed persistence is intentional: - Is a subagent fork expected to persist every historical `Compacted` record from the source rollout? - Is each earlier `replacement_history` expected to remain independently serialized after later compactions supersede it? - Is inline base64 image data expected to be repeated across every compaction snapshot and every full-history child fork? - Is there an intended upper bound for inherited persisted bytes when spawning a subagent? - Should proactive Ultra subagents have the same persistence behavior as an explicit user-created full thread fork? I can provide additional sanitized structural evidence if needed, including record-size distributions, parent/child metadata relationships, payload hash comparisons, compaction counts, and encoded image lengths. I cannot attach the complete affected rollouts because they are individually up to approximately 1.9 GB and contain private conversation and image data.", "url": "https://github.com/openai/codex/issues/34268", "createdAt": "2026-07-20T05:44:49Z", "updatedAt": "2026-08-13T12:46:17Z", "timestamp": "2026-08-13T12:46:17Z", "metrics": { "reactions": 6, "comments": 7 }, "labels": [ "bug", "context", "app", "subagent", "session" ], "author": "gonzalolarralde", "state": "open", "assignees": [] }, { "id": "github:openai/codex:issue:34351", "source": "github", "group": "coding-agent-infrastructure", "project": "openai/codex", "kind": "issue", "title": "Windows 11 Insider Build 26200: ChatGPT Desktop continuously flickers before login, renderer remains alive (OpenAI.Codex 26.715.7063.0)", "text": "### What version of the Codex App are you using (From “About Codex” dialog)? 26.715.7063.0 (Microsoft Store - OpenAI.Codex) ### What subscription do you have? ChatGPT Team ### What platform is your computer? Windows 11 x64 Insider Dev Build 26200 ### What issue are you seeing? ## Summary The ChatGPT Desktop application continuously flickers immediately after launch and never becomes usable. The login screen repeatedly refreshes, while the left sidebar and the main content area repaint independently at different frequencies. The application never crashes, and all renderer processes remain alive. This issue occurs every time the application starts. --- ## Environment - ChatGPT Desktop (Microsoft Store) - Package: OpenAI.Codex - Version: 26.715.7063.0 - Windows 11 Insider Dev Build 26200 - NVIDIA RTX 4070 Laptop GPU - Microsoft Edge WebView2 installed --- ## Expected behavior The desktop application should display the login page normally and allow user interaction. --- ## Actual behavior - Window continuously flickers. - Sidebar and main content repaint independently. - Login screen is never usable. - Application remains running. - No crash dialog appears. --- ## Troubleshooting already performed - Reinstalled ChatGPT Desktop. - Removed all application cache. - Removed package data. - Verified Microsoft Edge WebView2 installation. - Disabled GPU rendering using `--disable-gpu`. - Checked Windows Event Viewer (no crash logs). - Captured ProcMon logs (no ACCESS DENIED or abnormal failures). - Verified CPU usage is normal. - Verified GPU usage is normal. - Verified all ChatGPT renderer processes remain alive. - Verified process IDs remain unchanged over time. - Browser version of ChatGPT works normally. - Microsoft Store works normally. - VS Code and other Electron/Chromium applications work normally. --- ## Additional observations This issue started after the recent ChatGPT Desktop update in July 2026. Based on extensive troubleshooting, this appears to be a compatibility issue between ChatGPT Desktop version 26.715.7063.0 and Windows 11 Insider Dev Build 26200 rather than a local system configuration problem. ### What steps can reproduce the bug? 1. Start Windows 11 Insider Dev Build 26200. 2. Launch ChatGPT Desktop (OpenAI.Codex 26.715.7063.0). 3. Wait for the application to initialize. 4. Observe that the login page immediately begins flickering. 5. The sidebar and main content continue repainting indefinitely. 6. The application never becomes usable. ### What is the expected behavior? The ChatGPT Desktop application should open normally, display the login page once, and remain stable without any UI flickering. ### Additional information Additional diagnostics performed: - Renderer processes remain alive. - Process IDs remain unchanged. - No renderer recreation observed. - CPU usage remains stable. - GPU usage remains stable. - Event Viewer shows no application crash. - ProcMon shows no permission or file access failures. - Disabling GPU acceleration does not resolve the issue. Screen recording demonstrating the issue is attached. If needed, I can also provide: - ProcMon trace - PowerShell diagnostic logs - Additional system [information[](url)]( [ChatGPT_Developer_Diagnostic_Package.zip](https://github.com/user-attachments/files/30192099/ChatGPT_Developer_Diagnostic_Package.zip) [ChatGPT_BugReport_Attachment_Pack.zip](https://github.com/user-attachments/files/30192134/ChatGPT_BugReport_Attachment_Pack.zip) https://github.com/user-attachments/assets/2d54ad63-85d7-41c9-9799-4878bf3e34b0", "url": "https://github.com/openai/codex/issues/34351", "createdAt": "2026-07-20T14:13:09Z", "updatedAt": "2026-08-13T12:18:50Z", "timestamp": "2026-08-13T12:18:50Z", "metrics": { "reactions": 0, "comments": 5 }, "labels": [ "bug", "windows-os", "app" ], "author": "mengwuxiy", "state": "open", "assignees": [] }, { "id": "github:openai/codex:issue:34473", "source": "github", "group": "coding-agent-infrastructure", "project": "openai/codex", "kind": "issue", "title": "Codex App (Windows): an unresolvable git root causes an unbounded, no-backoff retry loop that saturates the entire machine — 142/168 git calls hit the 60s timeout", "text": "### What version of the Codex App are you using (From “About Codex” dialog)? Version 26.715.52143 ### What subscription do you have? Pro ### What platform is your computer? Microsoft Windows NT 10.0.26200.0 x64 ### What issue are you seeing? Codex App's git-root resolution retries **without any backoff, circuit breaker, or negative-result cache**. When a single path cannot be resolved, the retries compound until the entire machine is CPU-starved. This is not a slow-scan complaint — the machine became unusable and had to be force-powered-off. **The amplification, from the app's own logs.** Codex launched at 13:18:28. Sixteen seconds later its git worker began degrading. Raw `durationMs` values, 13:18:44 → 13:19:36: ``` 5,506 → 6,762 → 22,184 → 21,621 → 24,783 → 27,145 → 42,964 → 33,029 → 49,691 ms → then pinned at the 60,000 ms timeout ceiling, permanently ``` For reference, `git config --get remote.origin.url` completes in **10–40 ms** on this hardware. **Aggregate over the session:** | Metric | Value | |---|---| | git commands issued | 168 | | **git commands that timed out** | **142 (85%)** | | Median duration of timed-out calls | **60,007 ms** | | Duration of the loop | **54 minutes** | | `worker_rpc_response_error \"Failed to resolve git root\"` | **160** | | …explicitly `git process timed out after 60000ms` | **145** | | Repositories successfully scanned | **15 of 311** | **The loop:** ``` renderer → worker: resolve git root worker → spawn git.exe git.exe → hangs, 60 s timeout worker → worker_rpc_response_error \"Failed to resolve git root: git process timed out after 60000ms\" renderer → RETRY IMMEDIATELY ← no backoff, no circuit breaker, no failure cache ``` Each retry adds another 60-second `git.exe` to an already-starved machine, which makes the next git call slower still. This is **positive feedback, not a plateau** — it never self-limits. **Impact.** This is a 16-core / 32-thread / 96 GB workstation. It was fully saturated by the app's git scanner. The desktop became unresponsive and required a forced power-off after 54 minutes. It has happened **3 times in 48 hours**; on one occasion `taskkill.exe` **itself crashed** (`0xc0000005`) while attempting to terminate the app. **Measured CPU attribution (Windows SRUM, `powercfg /srumutil`).** CPU energy attributed to the WMI service (`svchost.exe [netsvcs] [Winmgmt]`), local time: | Local time | CPU energy | App state | |---|---|---| | 12:38 | 1,213,854 | not running | | **13:39** | **91,303,917** | **Codex launched — 75× jump** | | 14:08 | 74,046,292 | running | | **14:15+** | **7,000 – 44,000** | **not running — ~1000× collapse** | Total for the incident hour: **247,725,988** — the largest single CPU consumer on the machine, exceeding antivirus, shell, editor and a running backup **combined**. The post-restart period is a clean control. ### What steps can reproduce the bug? 1. Windows 11, Codex App (MSIX) `26.715.7063.0`. 2. A workspace root containing **many** git repositories (here: **311**). 3. Ensure at least one **`.git` path that git cannot resolve a root from** exists in that tree — in our case an **empty `.git` directory** (0 entries). 4. Launch the Codex App and let it scan. 5. Watch `durationMs` in `%LOCALAPPDATA%\\Packages\\OpenAI.Codex_\\LocalCache\\Local\\Codex\\Logs\\\\\\
\\`. Git durations climb from ~5 s to the 60 s ceiling within about a minute and stay there. The app keeps retrying for as long as it is left running. **Trigger confirmed by controlled test.** The unresolvable `.git` directory was deleted and the app relaunched with **no other change** — no app update, no antivirus exclusions, session data untouched. A monitor sampled `git.exe` count and total CPU every ~10 s: | | Before | After (unresolvable `.git` removed) | |---|---|---| | ~16 s after launch | durations already ramping (5,506 ms) | no git activity | | ~52 s after launch | pinned at the **60,000 ms** ceiling | **0 `git.exe` processes** | | Steady state | machine saturated, UI unresponsive | **CPU 3–8%, idle** | | Long-lived `git.exe` (>15 s) | dozens accumulating | **0** | | Outcome | forced power-off after 54 min | normal operation | ``` 15:10:03 Codex DETECTED: pid=9676 ChatGPT.exe 15:10:04 ok stuck_git=0 cpu=13% codexProcs=6 <- launch 15:10:16 ok stuck_git=0 cpu=50% codexProcs=10 <- normal Electron start-up burst 15:10:27 ok stuck_git=0 cpu=8% codexProcs=10 15:11:57 ok stuck_git=0 cpu=6% codexProcs=10 ``` Removing **one empty directory**, changing nothing else, eliminated the behaviour entirely. *(Caveat, stated plainly: this is a negative result over a single clean session. It shows the unresolvable path is sufficient to trigger the loop; it does not prove it is the only possible trigger — which is exactly why the retry behaviour needs bounding regardless of how the path arises.)* ### What is the expected behavior? The scanner should **fail fast and stay failed** for a path it cannot resolve: 1. **Backoff + circuit breaker** — a failing path must not be retried immediately, and repeated failures should disable scanning for that path. 2. **Cache negative results** — an unresolvable path should be remembered, not re-probed 145 times. 3. **Bound concurrency** — cap in-flight `git.exe` processes. Today, failures multiply the process count without limit, which is what converts a slow scan into machine-wide starvation. 4. **Validate before spawning** — an empty `.git` directory is detectable with a directory read; it does not require spawning git and waiting 60 seconds. Under no circumstances should a workspace-scanning feature be able to render the host unusable. ### Additional information **Two further Codex mechanisms were running concurrently and compounded the load.** Neither reproduced the saturation on its own once the git loop stopped, but both add constant overhead: 1. **PowerShell/WMI process sampler.** `electron-sampler` shells out to a **cold** `powershell.exe -NoProfile -NonInteractive` running **both** `Get-CimInstance Win32_PerfFormattedData_PerfProc_Process` **and** `Get-CimInstance Win32_Process`, with a PID filter enumerating 118 tracked children. These are the two most expensive process-enumeration calls on Windows (~1–2 CPU-seconds per invocation, fresh .NET start plus WMI provider work). Only *failures* are logged, and one 122-minute session logged **1,680 failed invocations** (7–11/min sustained). This is what drives the `svchost [Winmgmt]` figures above. A native API (`NtQuerySystemInformation` / Toolhelp32) would remove this entirely. 2. **Completed-rollout replay.** `~/.codex/sessions` here is **9.7 GB across 2,402 files**, largest single rollout **913 MB**; `logs_2.sqlite` is **2,147 MB** with a live WAL. Every telemetry write is random I/O into a 2 GB SQLite database on the system drive. **Onset correlates with an app update.** The 60-second git-timeout signature appears in exactly **3 of ~30** sessions, all within 48 hours, and in **none of the ~25 sessions before that**. The MSIX package updated on **2026-07-19**; the signature begins the following day. | Session | git timeouts | Outcome | |---|---|---| | Day 1, 09:59 → 13:58 | 61 | WER `MoAppHang` — \"Codex is not responding\" | | Day 1, 23:46 → 23:50 | 16 | `taskkill.exe` crashed (`0xc0000005`); machine hard-reset | | Day 2, 13:18 → 14:13 | **142** | Machine forcibly powered off | **Explicitly ruled out** as causes of the saturation, with evidence: Windows Update (no update activity in the window); pending disk check (the \"hybrid shutdown overridden\" event fired 4 ms *after* the shutdown request and also fires on ordinary shutdowns — a stale flag); disk failure (`chkdsk /scan` clean, **0 KB in bad sectors**, 0 uncorrected read/write errors, 0 wear); hardware/thermal (no WHEA events); memory exhaustion (no Event 2004; 96 GB installed); and one unrelated third-party application that was independently diagnosed and fixed earlier the same day — SRUM confirms it was idle at ~0.2 cores throughout this incident. **Possibly related existing issues:** #29911 (empty `.git` directories being created and rescanned — the *source* of the unresolvable path in our case), #29499 (WMI/PowerShell sampler; filed from **OS build 26200, identical to this machine**), #33786 (completed-thread rollout replay; same 26.715 build family), #30527 (antivirus exclusions shift rather than remove the cost). This report is filed separately from those because the failure documented here is not \"a directory gets rescanned\" but **unbounded retry amplification that terminates in whole-machine starvation and a forced power-off** — and because the trigger→fix relationship is confirmed by controlled measurement. **Redaction note:** Windows username, hostname, internal project names and session GUIDs have been removed from all excerpts above.", "url": "https://github.com/openai/codex/issues/34473", "createdAt": "2026-07-21T06:04:11Z", "updatedAt": "2026-08-12T17:37:46Z", "timestamp": "2026-08-12T17:37:46Z", "metrics": { "reactions": 0, "comments": 4 }, "labels": [ "bug", "windows-os", "app", "performance" ], "author": "jodagreyhame", "state": "open", "assignees": [] }, { "id": "github:openai/codex:issue:34499", "source": "github", "group": "coding-agent-infrastructure", "project": "openai/codex", "kind": "issue", "title": "Cannot create a local Work chat inside a ChatGPT Project (Windows Desktop App)", "text": "### What version of the Codex App are you using (From “About Codex” dialog)? 26.715.61943 (released July 21, 2026) ### What subscription do you have? ChatGPT Plus ### What platform is your computer? Microsoft Windows NT 10.0.22631.0 x64 ### What issue are you seeing? When I try to create a Work chat inside an existing ChatGPT Project, I immediately receive errors such as: - \"Could not sync ChatGPT project context\" - \"Could not use this project for a local chat\" The Work chat is not created. ### What steps can reproduce the bug? Feedback ID: 019f83d4-3c04-78a2-a4ce-3f1ff9273b23 ### What is the expected behavior? A Work chat should be created inside the existing ChatGPT Project and retain access to the selected local folder. A Project should be able to contain one or more Work chats with access to local development folders. ### Additional information The problem occurs only when creating a local Work chat inside an existing Project. Environment: - Windows Desktop App - ChatGPT Plus account - Codex App version 26.715.61943 - Codex extension in VS Code works correctly - Local folder access works outside Projects Could you please confirm whether this is a known issue or a bug? Screenshots showing the error can be attached.", "url": "https://github.com/openai/codex/issues/34499", "createdAt": "2026-07-21T09:16:59Z", "updatedAt": "2026-08-13T02:34:23Z", "timestamp": "2026-08-13T02:34:23Z", "metrics": { "reactions": 7, "comments": 16 }, "labels": [ "bug", "windows-os", "app", "session" ], "author": "Paul722", "state": "open", "assignees": [] }, { "id": "github:openai/codex:issue:34560", "source": "github", "group": "coding-agent-infrastructure", "project": "openai/codex", "kind": "issue", "title": "Codex desktop app default thread list does not include remote-ssh-codex-managed host after restart", "text": "### What version of the Codex App are you using (From “About Codex” dialog)? Codex CLI version: 0.142.3 ### What subscription do you have? Pro ### What platform is your computer? x86 ### What issue are you seeing? \"Image\" \"Image\" Codex desktop app default thread list does not include remote-ssh-codex-managed host after restart ### What steps can reproduce the bug? ### Environment - Codex CLI version: 0.142.3 - Codex App / Desktop remote SSH workflow - Remote host: remote-ssh-codex-managed:codexu - Remote cwd: /home/codexu/workdir - Remote user: codexu - Shell: bash - Date observed: 2026-07-21 - Config: disable_response_storage = false ### Issue After restarting Codex, history for the current remote directory appears missing in the default thread/history list. The records are not actually deleted. They exist locally on the remote host and can be found by search, but the default `list_threads` / recent history list does not include the `remote-ssh-codex-managed:codexu` host. ### Evidence On the remote host: - `/home/codexu/.codex/sessions` contains historical rollout files. - `/home/codexu/.codex/session_index.jsonl` contains the expected thread IDs. - `/home/codexu/.codex/state_5.sqlite` has 7 threads for `/home/codexu/workdir`. - Threads are not archived and have non-empty previews. Codex App behavior: - `list_projects` includes project `/home/codexu/workdir` with hostId `remote-ssh-codex-managed:codexu`. - `read_thread` works when passing `hostId=remote-ssh-codex-managed:codexu`. - `list_threads(query=\"workdir\")` returns the missing remote threads. - But default `list_threads(limit=50)` only returns `local` and `remote-ssh-discovered:codex_50`, not `remote-ssh-codex-managed:codexu`. ### Expected behavior Default recent thread list should include threads from all available hosts, including `remote-ssh-codex-managed:*`, merged and sorted by recency. ### Actual behavior Default recent thread list silently omits the `remote-ssh-codex-managed:codexu` host, making it look like history was lost after restart. ### Additional suspicious log `/home/codexu/.codex/app-server-control/app-server.log` contains: ```text Error: app-server control socket is already in use at /home/codexu/.codex/app-server-control/app-server-control.sock ### What is the expected behavior? _No response_ ### Additional information _No response_", "url": "https://github.com/openai/codex/issues/34560", "createdAt": "2026-07-21T15:02:58Z", "updatedAt": "2026-08-12T16:02:07Z", "timestamp": "2026-08-12T16:02:07Z", "metrics": { "reactions": 0, "comments": 1 }, "labels": [ "bug", "app", "app-server", "remote" ], "author": "xiuxiuing", "state": "open", "assignees": [], "change": "updated" }, { "id": "github:openai/codex:issue:34599", "source": "github", "group": "coding-agent-infrastructure", "project": "openai/codex", "kind": "issue", "title": "Messages sent during active work can be dropped instead of steering or queuing", "text": "### Summary In the Codex VS Code experience, messages sent while an agent is actively working can appear to be lost instead of being applied as a steer or retained in the queue for the next turn. The user then has to resend the correction. ### Environment - Codex VS Code extension build: `openai.chatgpt-26.715.31925-linux-x64` - Platform: Linux x86_64 - Observed: 2026-07-22 - Collaboration mode: Default ### Expected behavior A message sent while Codex is working should always do one of the documented actions: 1. steer the active turn; or 2. remain visibly queued for the next turn. It should never disappear without being applied or queued. ### Actual behavior During a long-running tool-using task, messages sent while the agent was working were not reliably surfaced as a steer or queued follow-up. The user perceived them as lost and had to resend them. Later messages could interrupt the active turn, but delivery/queue behavior was inconsistent. ### Reproduction outline 1. Start a long-running Codex task that performs multiple tool calls. 2. While the run is active, send one or more correction messages. 3. Continue interacting while the agent is between tool calls or waiting on tool output. 4. Observe whether every message is either acknowledged in the current turn or remains visibly queued. 5. In the failing case, a correction is neither visibly applied nor retained, so it must be resent. ### Impact This can cause user corrections or safety-relevant infrastructure details to be missed during active work. It also makes the user uncertain whether subsequent messages are safe to send before the current run finishes. ### Suggested investigation Please inspect client/server event sequencing around active-turn interruption, steer delivery, queue persistence, and turn-aborted transitions. A durable per-message delivery/acknowledgement state in the UI would make failures diagnosable. No repository contents, credentials, account identifiers, or private source details are included in this report.", "url": "https://github.com/openai/codex/issues/34599", "createdAt": "2026-07-21T19:18:18Z", "updatedAt": "2026-08-13T04:20:44Z", "timestamp": "2026-08-13T04:20:44Z", "metrics": { "reactions": 4, "comments": 4 }, "labels": [ "bug", "extension", "session" ], "author": "Aure-MandyP", "state": "open", "assignees": [] }, { "id": "github:openai/codex:issue:34696", "source": "github", "group": "coding-agent-infrastructure", "project": "openai/codex", "kind": "issue", "title": "IDE Context silently disables because workspaceRoot is missing in recent VS Code extension builds", "text": "### What version of the IDE extension are you using? Affected version: 26.715.61943. The same faulty IDE-context request construction was also found in 26.715.31925 and 26.707.91948. Version 26.5609.30741 works as a rollback. ### What subscription do you have? ChatGPT Plus ### Which IDE are you using? Visual Studio Code 1.129.1 ### What platform is your computer? Microsoft Windows NT 10.0.19045.0 x64 ### What issue are you seeing? In recent VS Code extension builds, IDE Context fails silently and then disables itself. When IDE Context is enabled, its indicator may appear briefly and then disappear. Codex can receive the active/open tab names, but it does not receive the active editor selection. The extension log contains: ```text 2026-07-22 13:48:35.560 [error] [Composer] failed to fetch ide-context error={} ``` A direct IPC diagnostic showed that a request containing the correct workspace root returns the IDE context successfully, while the same request with an empty workspace root returns no-client-found. Inspection of the shipped extension bundle shows that the webview's ide-context query constructs undefined request parameters, while the extension-side IPC handler requires workspaceRoot to route the request to the matching VS Code window. After this request fails, the frontend automatically disables IDE Context. The persisted composer-auto-context-enabled value is consequently reset to false, which explains why the indicator disappears. All third-party selection/context extensions were disabled during the final reproduction. Only the official openai.chatgpt extension was active. ### What steps can reproduce the bug? 1. Install the official `openai.chatgpt` VS Code extension version `26.715.61943` on Windows. 2. Open a local folder as a VS Code workspace. 3. Open a text or source file. 4. Select a unique line, for example: CODEX_IDE_CONTEXT_CANARY_7F3A9C 5.Open a local Codex conversation. 6.Enable IDE Context from the composer control or slash-command menu. 7.Send: Print the current selection verbatim. 8.Observe that the IDE Context indicator disappears and Codex can see only the open tab, not the selected text. 9.Check Codex.log; it contains [Composer] failed to fetch ide-context error={}. Control test: Downgrade and pin the official extension to 26.5609.30741. Enable the same official IDE Context option. Repeat the selection test. The exact selected text is transmitted successfully. ### What is the expected behavior? When IDE Context is enabled, the extension should keep the setting enabled and attach the active editor selection, active file, open tabs, and IDE metadata to the next Codex request A context-fetch failure should be shown to the user instead of silently disabling and persisting the feature as off. ### Additional information Runtime reproduction was confirmed with `26.715.61943`. The same faulty query construction is present in the shipped bundles for: - `26.715.31925` - `26.707.91948` Confirmed working workaround: - Install and pin the official `26.5609.30741` build. - Restore the official auto-context preference. - Selected text is then transmitted correctly. - No `failed to fetch ide-context` or `no-client-found` errors occur. This appears to be a webview-to-extension IPC routing regression, rather than a VS Code selection, workspace permission, authentication, or user-configuration problem.", "url": "https://github.com/openai/codex/issues/34696", "createdAt": "2026-07-22T07:31:32Z", "updatedAt": "2026-08-12T21:23:34Z", "timestamp": "2026-08-12T21:23:34Z", "metrics": { "reactions": 6, "comments": 4 }, "labels": [ "bug", "windows-os", "extension" ], "author": "sgggr", "state": "open", "assignees": [] }, { "id": "github:openai/codex:issue:34700", "source": "github", "group": "coding-agent-infrastructure", "project": "openai/codex", "kind": "issue", "title": "Codex App 26.715.9868.0 / CLI 0.145.0: spawn_agent rejects gpt-5.6-luna with multi_agent_v2 enabled", "text": "### What version of the Codex App are you using (From “About Codex” dialog)? 26.715.9868.0 (Windows package version) ### What subscription do you have? ChatGPT account; exact subscription tier is not displayed in this session. ### What platform is your computer? Microsoft Windows 11 Pro, NT 10.0.26200.0, x64 (build 26200) ### What issue are you seeing? The Codex desktop app is configured to use the standalone Codex CLI 0.145.0 through `CODEX_CLI_PATH`. The desktop log confirms that it spawned the external executable, and `codex --version` returns `codex-cli 0.145.0`. Both multi-agent flags are enabled: ```text multi_agent stable true multi_agent_v2 stable true ``` After fully restarting the desktop app, an explicit native subagent request with Luna and xhigh reasoning is rejected: ```json { \"fork_turns\": \"none\", \"model\": \"gpt-5.6-luna\", \"reasoning_effort\": \"xhigh\", \"task_name\": \"teste_luna_xhigh_v2\" } ``` Actual error: ```text Unknown model `gpt-5.6-luna` for spawn_agent. Available models: gpt-5.6-sol, gpt-5.6-terra ``` No child agent is created. The same result was reproduced after enabling MultiAgent V2 and restarting the app. ### What steps can reproduce the bug? 1. Install the official Windows x64 Codex CLI release 0.145.0. 2. Point the Codex desktop app to it using `CODEX_CLI_PATH=%LOCALAPPDATA%\\Programs\\OpenAI\\Codex\\bin\\codex.exe`. 3. Verify `codex --version` returns `codex-cli 0.145.0`. 4. Run `codex features enable multi_agent_v2` and verify both `multi_agent` and `multi_agent_v2` are true. 5. Fully quit and reopen the Codex desktop app. 6. In a desktop task, call the native `spawn_agent` tool with `fork_turns: \"none\"`, `model: \"gpt-5.6-luna\"`, and `reasoning_effort: \"xhigh\"`. 7. Observe the unknown-model error stating that only `gpt-5.6-sol` and `gpt-5.6-terra` are available. ### What is the expected behavior? If Luna is intended to be available for configurable MultiAgent V2 children on this account/backend, `spawn_agent` should accept `gpt-5.6-luna` with `xhigh` reasoning and create the child agent. If Luna is intentionally unavailable because of an account, rollout, backend, or entitlement restriction, the app should expose that limitation clearly and document how users can determine or obtain the required availability. Currently the local feature is stable and enabled, but the requested model remains impossible to select. ### Additional information The 0.145.0 release notes describe configurable sub-agent models/reasoning in MultiAgent V2 and mention GPT-5.6 Terra and Luna variants, which led to the expectation that Luna could be selected when using the new release. This appears distinct from #20077 (full-history inheritance/model override behavior) and #26753 (encrypted tool schema request failure): this report reaches the `spawn_agent` tool and is rejected specifically because Luna is absent from the active model catalog. The issue was reproduced multiple times. No files were modified by the failed subagent calls, and no child agent was created.", "url": "https://github.com/openai/codex/issues/34700", "createdAt": "2026-07-22T08:08:41Z", "updatedAt": "2026-08-13T10:49:22Z", "timestamp": "2026-08-13T10:49:22Z", "metrics": { "reactions": 36, "comments": 14 }, "labels": [ "bug", "windows-os", "app", "subagent" ], "author": "enzopresbiteris-rgb", "state": "open", "assignees": [] }, { "id": "github:openai/codex:issue:34764", "source": "github", "group": "coding-agent-infrastructure", "project": "openai/codex", "kind": "issue", "title": "Computer Use unavailable on Windows: Application Protected files fail to copy from WindowsApps", "text": "### What version of the Codex App are you using (From “About Codex” dialog)? 26.715.9868.0 ### What subscription do you have? plus ### What platform is your computer? Windows 11 x64 ### What issue are you seeing? Codex Computer Use fails on Windows when relocating Application Protected runtime files ## Summary Codex Desktop for Windows cannot initialize the bundled Computer Use plugin because the app fails while relocating the bundled `cua_node` runtime from the MSIX/WindowsApps installation directory into the per-user runtime cache. The source files are marked by Windows as `Encrypted` with compatibility level `Application Protected`. Both Codex's Node-based copy operation and standard Windows copy operations fail when copying these files to an ordinary user-writable destination. As a result, the Node REPL MCP backend is not exposed, the Computer Use helper/transport paths remain unavailable, and `list_apps` cannot be called. ## Environment - OS: Windows 11 x64 - Codex Desktop before reinstall: `26.715.8383.0` - Codex Desktop after reinstall: `26.715.9868.0` - Computer Use plugin: `26.715.61943` - Install type: Microsoft Store / MSIX - Install path shape: - `C:\\Program Files\\WindowsApps\\OpenAI.Codex__x64__\\app` - Runtime cache: - `%LOCALAPPDATA%\\OpenAI\\Codex\\runtimes\\cua_node` No VS Code Codex extension was present, so this report concerns the Codex Desktop app only. ## Reproduction 1. Install and start Codex Desktop from Microsoft Store. 2. Enable or invoke the bundled Computer Use plugin. 3. Ask Computer Use to list controllable applications. 4. Observe that `list_apps` is unavailable because the Node REPL backend is not loaded. ## Expected behavior Codex should relocate or otherwise expose the bundled `cua_node` runtime, initialize the Computer Use runtime, and make `list_apps` available. ## Actual behavior The runtime relocation fails while copying an encrypted source file such as `bin\\CHANGELOG.md` into a generated staging directory: ```text bundled_executable_relocation_failed errorCode=UNKNOWN errorMessage=\"Bundled executable relocation failed during copy_directory\" executableName=node.exe operation=copy_directory originalError={ \"errno\": -4094, \"code\": \"UNKNOWN\", \"syscall\": \"copyfile\", \"path\": \"C:\\\\Program Files\\\\WindowsApps\\\\OpenAI.Codex__x64__\\\\app\\\\resources\\\\cua_node\\\\bin\\\\CHANGELOG.md\", \"dest\": \"%LOCALAPPDATA%\\\\OpenAI\\\\Codex\\\\runtimes\\\\cua_node\\\\.staging-\\\\bin\\\\CHANGELOG.md\" } sourceKind=windowsapps ``` This is immediately followed by: ```text [computer-use-native-pipe] computer-use native pipe helper paths unavailable missingHelperPath=true missingTransportModulePath=true platform=win32 ``` The bundled plugin marketplace shows the same failure pattern when copying `.app.json` from WindowsApps into `%USERPROFILE%\\.codex\\.tmp`: ```text plugin_marketplace_folder_write_failed errorMessage=\"UNKNOWN: unknown error, copyfile '\\\\plugins\\\\sites\\\\.app.json' -> '%USERPROFILE%\\\\.codex\\\\.tmp\\\\bundled-marketplaces\\\\...\\\\plugins\\\\sites\\\\.app.json'\" ``` ## Encryption evidence `cipher /c` reports the failing source files as encrypted and Application Protected: ```text Attributes : Archive, Encrypted E CHANGELOG.md Compatibility Level: Application Protected E .app.json Compatibility Level: Application Protected ``` The destination runtime and plugin cache directories are ordinary unencrypted directories. Reading and hashing the source files succeeds, showing that the files exist and are readable. Copying them fails: ```text Copy-Item : The specified file could not be encrypted. ``` An EFS raw copy also fails before copying any files: ```text robocopy ... /EFSRAW ERROR 6000 (0x00001770) Accessing Destination Directory The specified file could not be encrypted. Files : 0 copied ``` Using `xcopy /G` successfully creates decrypted copies. A full `cua_node` copy produced 3,558 destination files, and SHA-256 hashes for `manifest.json`, `node.exe`, `node_repl.exe`, `codex-computer-use.exe`, and `helper_transport.js` matched their packaged sources. However, after restarting Codex, the app still performs its own copy into a new `.staging-` directory. That internal copy fails again, and Codex reports missing Computer Use helper paths despite the complete runtime already being present in the cache root. ## Troubleshooting already performed - Confirmed the Computer Use plugin and `computer-use-client.mjs` entry point exist. - Confirmed Chrome/Computer Use failure is not caused by a missing installation package. - Confirmed current sandbox setup runs complete with `errors=[]`. - No current `os error 740` failure. - No current native pipe `os error 2` failure. - No current `SetNamedSecurityInfoW failed: 5` failure. - Used Windows Settings **Repair** and restarted Codex: no change. - Uninstalled and reinstalled Codex from Microsoft Store to the system drive. - Reinstall updated Codex from `26.715.8383.0` to `26.715.9868.0`: no change. - Confirmed the post-reinstall failure has the same protected-source `copyfile` signature. - Copied the complete runtime with `xcopy /G` and verified file counts and hashes: Codex still retries and fails its own relocation step. ## Likely root cause Codex's Windows bundled-runtime relocation path uses a copy implementation that does not allow an encrypted/Application Protected source to be copied to an unencrypted destination. It returns Node/Win32 error `UNKNOWN (-4094)` rather than falling back to a decrypted-destination copy equivalent to Windows `xcopy /G` or `COPY_FILE_ALLOW_DECRYPTED_DESTINATION`. The runtime resolver treats relocation failure as fatal and returns no helper paths, even when a complete verified runtime already exists at the cache destination. ## Suggested product fixes 1. When the Windows source has Application Protected encryption, copy using a method that explicitly allows a decrypted destination. 2. Surface the underlying Windows error (`ERROR_ENCRYPTION_FAILED` / error 6000, if applicable) instead of only `UNKNOWN (-4094)`. 3. Validate and reuse an already complete runtime cache before attempting relocation again. 4. Apply the same protected-file handling to bundled plugin marketplace synchronization. 5. Add a Windows regression test using an encrypted/Application Protected source tree and an unencrypted destination. ## Safety note No registry, WindowsApps source file, ACL, application manifest, or Windows encryption policy was modified during troubleshooting. The manually copied runtime cache remains in place for inspection. ### What steps can reproduce the bug? Codex Computer Use fails on Windows when relocating Application Protected runtime files ## Summary Codex Desktop for Windows cannot initialize the bundled Computer Use plugin because the app fails while relocating the bundled `cua_node` runtime from the MSIX/WindowsApps installation directory into the per-user runtime cache. The source files are marked by Windows as `Encrypted` with compatibility level `Application Protected`. Both Codex's Node-based copy operation and standard Windows copy operations fail when copying these files to an ordinary user-writable destination. As a result, the Node REPL MCP backend is not exposed, the Computer Use helper/transport paths remain unavailable, and `list_apps` cannot be called. ## Environment - OS: Windows 11 x64 - Codex Desktop before reinstall: `26.715.8383.0` - Codex Desktop after reinstall: `26.715.9868.0` - Computer Use plugin: `26.715.61943` - Install type: Microsoft Store / MSIX - Install path shape: - `C:\\Program Files\\WindowsApps\\OpenAI.Codex__x64__\\app` - Runtime cache: - `%LOCALAPPDATA%\\OpenAI\\Codex\\runtimes\\cua_node` No VS Code Codex extension was present, so this report concerns the Codex Desktop app only. ## Reproduction 1. Install and start Codex Desktop from Microsoft Store. 2. Enable or invoke the bundled Computer Use plugin. 3. Ask Computer Use to list controllable applications. 4. Observe that `list_apps` is unavailable because the Node REPL backend is not loaded. ## Expected behavior Codex should relocate or otherwise expose the bundled `cua_node` runtime, initialize the Computer Use runtime, and make `list_apps` available. ## Actual behavior The runtime relocation fails while copying an encrypted source file such as `bin\\CHANGELOG.md` into a generated staging directory: ```text bundled_executable_relocation_failed errorCode=UNKNOWN errorMessage=\"Bundled executable relocation failed during copy_directory\" executableName=node.exe operation=copy_directory originalError={ \"errno\": -4094, \"code\": \"UNKNOWN\", \"syscall\": \"copyfile\", \"path\": \"C:\\\\Program Files\\\\WindowsApps\\\\OpenAI.Codex__x64__\\\\app\\\\resources\\\\cua_node\\\\bin\\\\CHANGELOG.md\", \"dest\": \"%LOCALAPPDATA%\\\\OpenAI\\\\Codex\\\\runtimes\\\\cua_node\\\\.staging-\\\\bin\\\\CHANGELOG.md\" } sourceKind=windowsapps ``` This is immediately followed by: ```text [computer-use-native-pipe] computer-use native pipe helper paths unavailable missingHelperPath=true missingTransportModulePath=true platform=win32 ``` The bundled plugin marketplace shows the same failure pattern when copying `.app.json` from WindowsApps into `%USERPROFILE%\\.codex\\.tmp`: ```text plugin_marketplace_folder_write_failed errorMessage=\"UNKNOWN: unknown error, copyfile '\\\\plugins\\\\sites\\\\.app.json' -> '%USERPROFILE%\\\\.codex\\\\.tmp\\\\bundled-marketplaces\\\\...\\\\plugins\\\\sites\\\\.app.json'\" ``` ## Encryption evidence `cipher /c` reports the failing source files as encrypted and Application Protected: ```text Attributes : Archive, Encrypted E CHANGELOG.md Compatibility Level: Application Protected E .app.json Compatibility Level: Application Protected ``` The destination runtime and plugin cache directories are ordinary unencrypted directories. Reading and hashing the source files succeeds, showing that the files exist and are readable. Copying them fails: ```text Copy-Item : The specified file could not be encrypted. ``` An EFS raw copy also fails before copying any files: ```text robocopy ... /EFSRAW ERROR 6000 (0x00001770) Accessing Destination Directory The specified file could not be encrypted. Files : 0 copied ``` Using `xcopy /G` successfully creates decrypted copies. A full `cua_node` copy produced 3,558 destination files, and SHA-256 hashes for `manifest.json`, `node.exe`, `node_repl.exe`, `codex-computer-use.exe`, and `helper_transport.js` matched their packaged sources. However, after restarting Codex, the app still performs its own copy into a new `.staging-` directory. That internal copy fails again, and Codex reports missing Computer Use helper paths despite the complete runtime already being present in the cache root. ## Troubleshooting already performed - Confirmed the Computer Use plugin and `computer-use-client.mjs` entry point exist. - Confirmed Chrome/Computer Use failure is not caused by a missing installation package. - Confirmed current sandbox setup runs complete with `errors=[]`. - No current `os error 740` failure. - No current native pipe `os error 2` failure. - No current `SetNamedSecurityInfoW failed: 5` failure. - Used Windows Settings **Repair** and restarted Codex: no change. - Uninstalled and reinstalled Codex from Microsoft Store to the system drive. - Reinstall updated Codex from `26.715.8383.0` to `26.715.9868.0`: no change. - Confirmed the post-reinstall failure has the same protected-source `copyfile` signature. - Copied the complete runtime with `xcopy /G` and verified file counts and hashes: Codex still retries and fails its own relocation step. ## Likely root cause Codex's Windows bundled-runtime relocation path uses a copy implementation that does not allow an encrypted/Application Protected source to be copied to an unencrypted destination. It returns Node/Win32 error `UNKNOWN (-4094)` rather than falling back to a decrypted-destination copy equivalent to Windows `xcopy /G` or `COPY_FILE_ALLOW_DECRYPTED_DESTINATION`. The runtime resolver treats relocation failure as fatal and returns no helper paths, even when a complete verified runtime already exists at the cache destination. ## Suggested product fixes 1. When the Windows source has Application Protected encryption, copy using a method that explicitly allows a decrypted destination. 2. Surface the underlying Windows error (`ERROR_ENCRYPTION_FAILED` / error 6000, if applicable) instead of only `UNKNOWN (-4094)`. 3. Validate and reuse an already complete runtime cache before attempting relocation again. 4. Apply the same protected-file handling to bundled plugin marketplace synchronization. 5. Add a Windows regression test using an encrypted/Application Protected source tree and an unencrypted destination. ## Safety note No registry, WindowsApps source file, ACL, application manifest, or Windows encryption policy was modified during troubleshooting. The manually copied runtime cache remains in place for inspection. ### What is the expected behavior? _No response_ ### Additional information _No response_", "url": "https://github.com/openai/codex/issues/34764", "createdAt": "2026-07-22T14:35:43Z", "updatedAt": "2026-08-13T11:46:32Z", "timestamp": "2026-08-13T11:46:32Z", "metrics": { "reactions": 0, "comments": 5 }, "labels": [ "bug", "windows-os", "app", "computer-use" ], "author": "lizixian518-cell", "state": "open", "assignees": [] }, { "id": "github:openai/codex:issue:34776", "source": "github", "group": "coding-agent-infrastructure", "project": "openai/codex", "kind": "issue", "title": "/agent command takes extremely long to switch back to the main agent", "text": "### What version of Codex CLI is running? codex-cli 0.145.0 ### What subscription do you have? Pro 20x ### Which model were you using? gpt-5.6-luna ### What platform is your computer? Linux 6.18.33.2-microsoft-standard-WSL2 x86_64 x86_64 ### What terminal emulator and version are you using (if applicable)? Windows Terminal ### Codex doctor report ```json { \"schemaVersion\": 1, \"generatedAt\": \"1784733292s since unix epoch\", \"overallStatus\": \"warning\", \"codexVersion\": \"0.145.0\", \"checks\": { \"app_server.status\": { \"id\": \"app_server.status\", \"category\": \"app-server\", \"status\": \"ok\", \"summary\": \"background server is not running\", \"details\": { \"control socket\": \"/home/gili/cat/.codex/app-server-control/app-server-control.sock\", \"daemon state dir\": \"/home/gili/cat/.codex/app-server-daemon\", \"mode\": \"ephemeral\", \"pid file\": \"/home/gili/cat/.codex/app-server-daemon/app-server.pid (missing)\", \"settings\": \"/home/gili/cat/.codex/app-server-daemon/settings.json (missing)\", \"status\": \"not running\", \"update-loop pid file\": \"/home/gili/cat/.codex/app-server-daemon/app-server-updater.pid (missing)\" }, \"remediation\": null, \"durationMs\": 0 }, \"auth.credentials\": { … +301 lines (ctrl + t to view transcript) \"terminal title project value\": \"2.1-add-divide-and-co...\", \"terminal title source\": \"default\" }, \"remediation\": null, \"durationMs\": 0 }, \"updates.status\": { \"id\": \"updates.status\", \"category\": \"updates\", \"status\": \"ok\", \"summary\": \"update configuration is locally consistent\", \"details\": { \"cached latest version\": \"0.145.0\", \"check for update on startup\": \"true\", \"last checked at\": \"2026-07-22T14:22:04.036380264Z\", \"latest version\": \"0.145.0\", \"latest version status\": \"current version is not older\", \"update action\": \"manual or unknown\", \"version cache\": \"/home/gili/cat/.codex/version.json\" }, \"remediation\": null, \"durationMs\": 262 } } } ``` ### What issue are you seeing? I am seeing a major performance regression when switching agents or resuming sessions in version 0.145.0 compared to 0.144.6. In version 0.144.6, switching agents using `/agent` was almost instantaneous. Resuming the session took ~15-30 seconds, not 8 minutes. In version 0.145.0 resuming the session or using `/agent` to switch from a subagent back to the main agent takes 8 minutes to complete with little to no visible CPU, disk or network usage. Switching from the main agent to a subagent remains fast. ### What steps can reproduce the bug? Uploaded thread: 019f6908-95ff-73d2-92c5-ba698e0e9bec ### What is the expected behavior? - Switching between agents using `/agent` should take no longer than 2 seconds - Resuming sessions should take no longer than 15 seconds. Consider showing a progress indicator for long operations. ### Additional information This is a long session, spanning continuous work over ~2-3 days of work.", "url": "https://github.com/openai/codex/issues/34776", "createdAt": "2026-07-22T15:40:08Z", "updatedAt": "2026-08-13T04:16:06Z", "timestamp": "2026-08-13T04:16:06Z", "metrics": { "reactions": 1, "comments": 2 }, "labels": [ "bug", "CLI", "subagent", "session", "performance" ], "author": "cowwoc", "state": "open", "assignees": [] }, { "id": "github:openai/codex:issue:34794", "source": "github", "group": "coding-agent-infrastructure", "project": "openai/codex", "kind": "issue", "title": "[macOS] Scheduled automation returns to sleep after dispatch during DarkWake", "text": "### What version of the Codex App are you using (From “About Codex” dialog)? 26.715.72028 (5706) ### What subscription do you have? Not relevant to reproduction ### What platform is your computer? `Darwin 25.5.0 arm64 arm` macOS 26.5.2 (25F84), MacBookAir10,1 (Apple M1), connected to AC through an Apple Studio Display in closed-clamshell mode. ### What issue are you seeing? A local scheduled automation was dispatched while the Mac was in DarkWake, with the Codex app running and sleep prevention enabled. The turn started, but macOS returned to sleep 45 seconds later. The automation then made no meaningful progress until a full user-activity wake, after which it resumed and completed shortly afterward. Observed timeline (local time): ```text 09:13:33 Codex scheduled automation turn dispatched 09:13:34 DarkWake from Deep Idle ... rtc/SleepService, Using AC 09:14:19 Entering Sleep due to 'Sleep Service Back to Sleep', Using AC 10:17:33 Full Wake ... UserActivity Assertion, Using AC 10:23:57 Automation completed ``` The automation had only about 12m45s of active execution but roughly 57 minutes of suspension/wall-clock delay. Waking the Mac through user activity allowed it to finish. This makes unattended local scheduled automations unreliable: Codex can dispatch and mark a turn active during a short maintenance wake, but that active turn does not keep the machine awake long enough to finish. ### What steps can reproduce the bug? 1. On a Mac connected to AC, remain logged in with the Codex desktop app running. 2. Enable Codex's sleep-prevention / “Prevent sleep while running” behavior. 3. Leave normal system sleep enabled (in this case AC system sleep was 10 minutes; display sleep was allowed). 4. Create a local scheduled automation whose work lasts more than a minute and uses normal app/plugin calls. 5. Let the Mac enter system sleep before the scheduled time. 6. Allow the scheduler to dispatch the automation during a maintenance DarkWake without interacting with the Mac. 7. Inspect `pmset -g log`: the automation turn starts, but macOS records `Sleep Service Back to Sleep` shortly afterward. 8. Wake the Mac through user activity. The same turn resumes and completes without another instruction. ### What is the expected behavior? Once a scheduled automation has dispatched and has an active turn, Codex should keep the Mac sufficiently awake to complete that turn, while still allowing display sleep. On AC power, this could use a bounded `PreventSystemSleep` assertion (or equivalent) that is released when the turn completes. A scheduled turn should not remain suspended until the user wakes the Mac. ### Additional information Codex's current macOS sleep inhibitor requests `PreventUserIdleSystemSleep`: https://github.com/openai/codex/blob/main/codex-rs/utils/sleep-inhibitor/src/macos.rs That assertion does not prevent the observed `Sleep Service Back to Sleep` transition during DarkWake. A bounded external workaround using `pmset repeat wakeorpoweron` followed by `/usr/bin/caffeinate -s` (`PreventSystemSleep`, AC only) keeps the same automation reliable without preventing display sleep. Related issues: - #23294 reports the general “Keep this Mac awake” setting failing to prevent sleep, but does not document an already-dispatched scheduled turn returning to sleep during DarkWake. - #32425 concerns scheduled tasks and a ChatGPT Classic interaction, not this power-assertion sequence. - #31584 is an adjacent automation stall caused by an app tool call/UI activation, not confirmed system sleep. I searched open issues for `DarkWake`, `Sleep Service Back to Sleep`, and the two assertion names and did not find this exact automation failure signature.", "url": "https://github.com/openai/codex/issues/34794", "createdAt": "2026-07-22T17:13:35Z", "updatedAt": "2026-08-13T06:24:13Z", "timestamp": "2026-08-13T06:24:13Z", "metrics": { "reactions": 0, "comments": 1 }, "labels": [ "bug", "app", "automations" ], "author": "mtarnovan", "state": "open", "assignees": [] }, { "id": "github:openai/codex:issue:34807", "source": "github", "group": "coding-agent-infrastructure", "project": "openai/codex", "kind": "issue", "title": "ChatGPT Desktop startup rewrites bundled computer-use MCP to enabled=false while plugin stays enabled", "text": "### Summary Launching ChatGPT Desktop on macOS rewrites the shared `~/.codex/config.toml` entry for the bundled `computer-use` MCP server to `enabled = false`, while leaving `computer-use@openai-bundled` itself enabled. The next CLI read confirms that the MCP is disabled. This is a persistence/reconciliation defect, not a missing or unsigned helper. The official [Computer Use setup documentation](https://learn.chatgpt.com/docs/computer-use) exposes two separate controls and instructs users to turn on both the Computer Use server and skill toggles. It does not document a launch-time reset of either control. ### Reproduction 1. Install and enable the bundled Computer Use plugin. 2. Enable its MCP server and verify both persisted states: ```toml [plugins.\"computer-use@openai-bundled\"] enabled = true [mcp_servers.computer-use] command = \"\" args = [\"mcp\"] cwd = \"\" enabled = true ``` 3. Fully launch ChatGPT Desktop. 4. Read only the two relevant sections of `~/.codex/config.toml`, then run `codex mcp get computer-use`. ### Expected behavior ChatGPT Desktop should preserve the user's enabled MCP state while reconciling the first-party bundled plugin. If path normalization is required, it should not change the enablement decision. ### Actual behavior The plugin remains enabled: ```toml [plugins.\"computer-use@openai-bundled\"] enabled = true ``` But the MCP entry is rewritten to: ```toml [mcp_servers.computer-use] command = \"./Codex Computer Use.app/Contents/SharedSupport/SkyComputerUseClient.app/Contents/MacOS/SkyComputerUseClient\" args = [\"mcp\"] cwd = \".\" enabled = false ``` `codex mcp get computer-use` then reports: ```text computer-use (disabled) ``` ### Timestamped before/after evidence All timestamps below are from the same Mac in Europe/Lisbon time on July 22, 2026: | Time | Observed state | | --- | --- | | 17:41:01 WEST | Known-good config backup contains the valid absolute bundled-helper path and `enabled = true`; the plugin is also enabled. | | 19:16:48 WEST | `/Applications/ChatGPT.app/Contents/MacOS/ChatGPT` starts. | | 19:16:49 WEST | ChatGPT's embedded `codex ... app-server` starts. | | 19:16:58 WEST | `~/.codex/config.toml` mtime changes; the MCP stanza now has the relative command/cwd shown above and `enabled = false`. | This establishes a launch-correlated write to the shared config. It does not identify which internal ChatGPT reconciliation component performed the write. ### Bundled manifest and signature evidence The first-party plugin manifest supplies command resolution but no enablement policy: ```json {\"mcpServers\":{\"computer-use\":{\"command\":\"./Codex Computer Use.app/Contents/SharedSupport/SkyComputerUseClient.app/Contents/MacOS/SkyComputerUseClient\",\"args\":[\"mcp\"],\"cwd\":\".\"}}} ``` Byte-identical copies of this manifest are present in the ChatGPT app bundle, the user plugin cache, and the generated bundled-marketplace snapshot. None contains an `enabled` field. The corresponding helper app in each of those three locations passes strict/deep code-signature verification with: ```text Identifier=com.openai.sky.CUAService Authority=Developer ID Application: OpenAI OpCo, LLC (2DC432GLL2) TeamIdentifier=2DC432GLL2 ``` There is therefore no evidence here of a corrupt, modified, or unsigned Computer Use bundle. ### Environment - macOS 26.5.2 (25F84), Apple Silicon (`arm64`) - ChatGPT Desktop 26.715.72359, bundle build 5718 - Embedded CLI: `codex-cli 0.145.0-alpha.30` - PATH CLI: `codex-cli 0.145.0` - Computer Use helper 26.715.1000451, build 1000451 ### Non-duplication and scope boundary - #25809 and #26429 concern restart instability, missing/uninstalled plugins, marketplace races, stale paths, or tools not attaching. This reproduction retains the plugin and isolates a persisted `enabled = true` to `enabled = false` MCP rewrite during ChatGPT launch. - #34110 concerns effective runtime disabling from plugin requirement filtering, not a physical launch-time rewrite of the user's MCP stanza. - A separate stale app-server from an older runtime was present with PPID 1 and an old control socket. It started the previous day. It is a cleanup concern, but no evidence attributes the 19:16:58 config write to it, so it is not presented as the cause. ### Requested fix Please make first-party plugin/MCP reconciliation preserve the user's persisted Computer Use server enablement, or establish one authoritative persisted setting that keeps the plugin and MCP controls synchronized. Rewriting command/cwd fields must not silently reset `enabled` to `false`. The supported fix should live in the first-party reconciliation path. Users should not need to patch signed app/plugin bundles, run a config watchdog, or maintain a persistent override merely to retain the documented enabled state across launch.", "url": "https://github.com/openai/codex/issues/34807", "createdAt": "2026-07-22T18:44:39Z", "updatedAt": "2026-08-12T14:53:54Z", "timestamp": "2026-08-12T14:53:54Z", "metrics": { "reactions": 2, "comments": 3 }, "labels": [ "bug", "mcp", "app", "config", "computer-use" ], "author": "jjoanna2-debug", "state": "open", "assignees": [], "change": "updated" }, { "id": "github:openai/codex:issue:34833", "source": "github", "group": "coding-agent-infrastructure", "project": "openai/codex", "kind": "issue", "title": "MultiAgentV2 cross-provider subagent cannot consume encrypted task assignment", "text": "## Summary With an OpenAI parent and a correctly selected non-OpenAI custom-provider child, MultiAgentV2 delivers the child assignment only as encrypted content that the custom-provider model cannot consume. The spawned child metadata shows the intended custom role, provider, model, and MultiAgentV2 implementation, but the child sees an empty visible `Payload:` and reports that it has no assignment. A same-provider OpenAI child consumes an otherwise equivalent encrypted assignment successfully. ## Environment - Codex CLI: 0.145.0 - Surface: Codex desktop connected to a remote Codex app-server over SSH - Multi-agent version: v2 - Parent provider: OpenAI - Child role: registered custom agent - Child provider: non-OpenAI, OpenAI-compatible Chat Completions provider - Child model: Kimi K3 ## Reproduction 1. Enable `multi_agent_v2`. 2. Configure a registered custom child agent using a non-OpenAI provider and an OpenAI-compatible Chat Completions model. 3. Start an OpenAI-backed parent. 4. Spawn the custom child with a unique harmless marker and an explicit instruction to run `pwd`. 5. Inspect the spawned session metadata and child handoff. The session metadata confirms: - `agent_role` is the registered custom role. - `multi_agent_version` is `v2`. - `model_provider` is the intended custom provider. - `model` is the intended custom model. The stored handoff displays an empty `Payload:` and contains an encrypted-content block. The child reports that it received no assignment and does not execute the marker or `pwd`. In a related continuation path, the parent can terminate with: `Encrypted function output content could not be decrypted or decoded.` ## Control: same-provider child Repeat the test with an OpenAI child. Its stored handoff also displays an empty visible `Payload:` plus encrypted content, but the OpenAI child successfully consumes the assignment, reproduces the marker, runs `pwd`, and returns the expected path. This indicates that general v2 dispatch works and that the problem is specific to the provider boundary. ## Control: provider-neutral delivery As a diagnostic only, provide the same assignment to the custom child through a single-use, permission-restricted, nonce-bound local file referenced by the custom agent's developer instructions. The custom child then executes the marker and `pwd` successfully. This confirms that: - The custom provider and model are operational. - Child provider/model selection works. - The task itself is valid. - Failure occurs when the assignment is carried only through the encrypted MultiAgentV2 field. A fixed file inbox is not a safe permanent workaround because of stale-task, concurrency, cleanup, attribution, and local instruction-injection risks. ## Expected behavior Codex should make the assignment available to the selected child in a representation that its configured provider can consume. Possible implementations include decrypting/translating the assignment within Codex before invoking a provider that does not support OpenAI encrypted tool parameters, or explicitly rejecting unsupported cross-provider delegation before spawning the child. ## Actual behavior The custom child is spawned with the correct role, provider, and model, but cannot consume the encrypted assignment and behaves as though no task was supplied. ## Related issues - #33267 - exact decryption error when consuming MultiAgentV2 child results - #17541 - provider-specific encrypted content retained across a provider/model boundary - #26753 - MultiAgentV2 agent tools use encrypted parameters - #27205 - model not configured for encrypted tool use - #17598 - native subagent orchestration with non-OpenAI custom providers - #32753 - encrypted MultiAgentV2 assignments are no longer observable ## Additional notes This is not a request to support a CPA-backed parent. The failing topology is specifically: OpenAI parent -> registered non-OpenAI custom-provider child Please let me know which narrowly scoped logs or sanitized session records would help. I have intentionally omitted authorization data, internal network details, complete encrypted blobs, and unrelated prompts.", "url": "https://github.com/openai/codex/issues/34833", "createdAt": "2026-07-22T21:36:34Z", "updatedAt": "2026-08-13T14:21:22Z", "timestamp": "2026-08-13T14:21:22Z", "metrics": { "reactions": 3, "comments": 10 }, "labels": [ "bug", "custom-model", "app", "subagent", "app-server" ], "author": "qqq-jump", "state": "open", "assignees": [] }, { "id": "github:openai/codex:issue:34920", "source": "github", "group": "coding-agent-infrastructure", "project": "openai/codex", "kind": "issue", "title": "IDE Context fails in Codex extension 26.715.x with RPC serialization error", "text": "## Environment - OS: Windows - Codex IDE extension: 26.715.31925 - Also observed in: 26.707.91948 and 26.715.61943 - IDEs tested: Visual Studio Code and Devin - GPT-5.6 is available in newer extension builds, but IDE Context is broken ## Problem IDE Context does not work in recent Codex extension versions. The extension logs: ~~~text [Composer] failed to fetch ide-context error={} ~~~ The extension detects the active file, open tabs, and selected text, but this context is not included in the prompt. The Composer then silently disables or persists the IDE Context state as disabled. The same behavior was reproduced in both VS Code and Devin, so this does not appear to be specific to one IDE installation. ## Steps to reproduce 1. Install Codex IDE extension 26.715.31925. 2. Open a workspace in VS Code or Devin. 3. Enable IDE Context / automatic IDE context. 4. Open a file, select some text, and keep multiple tabs open. 5. Send a prompt through Composer. 6. Check the extension log or inspect the prompt payload. ## Actual behavior - The IDE bridge can return the active file, open tabs, and selected text. - Sending the IDE context through the client-coordination RPC fails. - The prompt is sent without IDE context. - The log only shows `[Composer] failed to fetch ide-context error={}`. - The IDE Context state may be automatically disabled afterward. The underlying error observed while instrumenting the provider was: ~~~text OA.getIdeContext() TypeError: Cannot serialize value: [object Object] ~~~ ## Expected behavior The active file, open tabs, and selected text should be serialized and included automatically in the submitted prompt. ## Root cause investigation The IDE context provider returns VS Code / editor class instances, including selection-position objects, instead of plain JSON data. The client-coordination RPC serializer cannot serialize these class instances. The failing implementation was: ~~~js getIdeContext(e) { return Promise.resolve(this.#e()); } ~~~ Normalizing the value to plain JSON fixes the RPC boundary: ~~~js getIdeContext(e) { return Promise.resolve(JSON.parse(JSON.stringify(this.#e()))); } ~~~ ## Verified workaround After applying the JSON normalization above and reloading the IDE: - IDE Context remains enabled. - The active file is included in new prompts. - Open tabs are included in new prompts. - Selected text is included in new prompts. - The `failed to fetch ide-context` error no longer occurs. The older extension version 26.5609.30741 also avoids this failure, but it does not provide GPT-5.6 support. ## Suggested fix Convert the IDE context result to a plain serializable object before sending it through the RPC layer. A structured normalization or explicit DTO mapping would be preferable if the payload shape is known. Please consider adding a regression test that passes VS Code Selection / Position objects through `getIdeContext()` and verifies that the resulting RPC payload is JSON-serializable. This appears to be an extension-side regression rather than an OpenAI service outage, account issue, or model problem.", "url": "https://github.com/openai/codex/issues/34920", "createdAt": "2026-07-23T10:14:37Z", "updatedAt": "2026-08-12T21:25:07Z", "timestamp": "2026-08-12T21:25:07Z", "metrics": { "reactions": 5, "comments": 10 }, "labels": [ "bug", "windows-os", "extension", "tool-calls" ], "author": "ConelDEV", "state": "open", "assignees": [] }, { "id": "github:openai/codex:issue:35113", "source": "github", "group": "coding-agent-infrastructure", "project": "openai/codex", "kind": "issue", "title": "[Windows] Codex desktop incorrectly shows “You don’t have access to Codex yet” and does not load account information", "text": "### What version of the Codex App are you using (From “About Codex” dialog)? 26.721.31836 ### What subscription do you have? Plus ### What platform is your computer? Microsoft Windows NT 10.0.26200.0 x64 ### What issue are you seeing? The Codex desktop app does not load the home page correctly on one of my Windows PCs. The app recognizes that I am signed in, but the main page is blank or incomplete, my recent projects/tasks are missing, and account-related information such as usage limits is not displayed correctly. The same ChatGPT account works normally on two other computers, so this appears to be specific to the local installation or cached application state on this PC. \"Image\" \"Image\" ### What steps can reproduce the bug? Feedback ID: no-active-thread-019f92cd-a4e2-7ec0-8506-eb59b0dd82b1 ### What is the expected behavior? _No response_ ### Additional information I have already tried: Signing out and signing in again Resetting the application through Windows Settings Uninstalling and reinstalling the desktop app Restarting Windows Removing local Codex cache/application data Reinstalling the latest version Verifying that the same account works normally on other PCs None of these steps resolved the issue.", "url": "https://github.com/openai/codex/issues/35113", "createdAt": "2026-07-24T06:42:30Z", "updatedAt": "2026-08-13T01:46:15Z", "timestamp": "2026-08-13T01:46:15Z", "metrics": { "reactions": 5, "comments": 8 }, "labels": [ "bug", "windows-os", "auth", "app" ], "author": "adechen-w", "state": "closed", "assignees": [] }, { "id": "github:openai/codex:issue:35156", "source": "github", "group": "coding-agent-infrastructure", "project": "openai/codex", "kind": "issue", "title": "Codex not showing diff", "text": "### What version of the IDE extension are you using? 26.721.30844 ### What subscription do you have? Plus ### Which IDE are you using? Vs code ### What platform is your computer? _No response_ ### What issue are you seeing? I cant´t see the codex diff , i click the button \"Review\" to see what have changed but this \"Oops, an error has occurred\" appears in the screen whit a button with the text \"try again\" I click it and the window changes showing me in the screen \"No diff available\" ### What steps can reproduce the bug? . ### What is the expected behavior? _No response_ ### Additional information _No response_", "url": "https://github.com/openai/codex/issues/35156", "createdAt": "2026-07-24T11:26:23Z", "updatedAt": "2026-08-13T16:24:52Z", "timestamp": "2026-08-13T16:24:52Z", "metrics": { "reactions": 37, "comments": 5 }, "labels": [ "bug", "code-review", "extension" ], "author": "garzastrabajo", "state": "open", "assignees": [] }, { "id": "github:openai/codex:issue:35210", "source": "github", "group": "coding-agent-infrastructure", "project": "openai/codex", "kind": "issue", "title": "[Windows][Codex Desktop][IAB] `browser.tabs.finalize()` silently terminates the entire app", "text": "## Environment - **Codex Desktop package:** `26.721.3996.0` (Microsoft Store / MSIX, x64) - **Bundled Browser Use release:** `26.721.31836` - **OS:** Windows 11 x64 - **Authentication/subscription:** ChatGPT account in Codex Desktop (tier intentionally omitted) ## What issue are you seeing? Calling `browser.tabs.finalize(...)` from the bundled in-app browser (`iab`) can silently terminate the **entire Codex Desktop AppX process tree**, not just close the browser tabs. Any other concurrently running Codex tasks are interrupted at the same time. There is no crash dialog. Windows does not record an `Application Error` / WER crash, and no crash dump is produced. The AppModel Runtime log only shows that the Codex AppX container was destroyed. This has reproduced twice on the same build with two different forms of empty finalization: 1. `await browser.tabs.finalize({keep:[]});` 2. `await browser.tabs.finalize({});` In both cases the tool call itself returned successfully before the desktop process disappeared. ## Steps to reproduce 1. Start Codex Desktop on Windows. 2. Run a task that uses the bundled in-app Browser Use backend. 3. Optionally keep another task running in a different project (this makes the cross-task impact visible). 4. At the end of Browser Use, run: ```js await viewport.reset(); await browser.tabs.finalize({}); ``` 5. Observe that the tool call completes, the IAB guest/webview is torn down, and then the entire Codex Desktop process exits. Other active tasks become `interrupted` with no task-level error. ## Deterministic timing evidence ### Occurrence A - `browser.tabs.finalize({keep:[]})` starts - the desktop log stops approximately **156 ms later** - Windows AppModel Runtime then records the Codex AppX container being destroyed ### Occurrence B - `browser.tabs.finalize({})` starts - Browser Use returns successfully - the function-call output is persisted - the final desktop log is written approximately **151 ms after the call began** - Windows AppModel Runtime then records the Codex AppX container being destroyed - Codex relaunches into a new AppX container Sanitized final lifecycle sequence from occurrence B: ```text IAB_LIFECYCLE unregistered debugger listener ... reason=manual ... webContentsDestroyed=false IAB_LIFECYCLE syncing browser use active state ... isActive=false IAB_LIFECYCLE renderer synced browser use webview state ... isBrowserUseActive=false IAB_LIFECYCLE renderer disposed browser sidebar webview IAB_LIFECYCLE browser sidebar guest torn down IAB_LIFECYCLE renderer removed browser sidebar webview ... tabType=closed IAB_LIFECYCLE closed browser sidebar page IAB_TAB_ANALYTICS browser tab lifecycle action=closed ... appBrowserTabCount=2 appBrowserUseTabCount=0 ``` The last call was recorded as completed; no task cancellation, interrupt request, fatal log, OOM event, WER report, or crash dump preceded the container destruction. ## Possible lifecycle clue The IAB registry initially creates/captures a browser route under a temporary `client-new-thread:` conversation ID. After the real thread is created, logs show route reassignment/rebinding between the real thread ID and that temporary client ID. During finalization, the closed browser tab is still logged under the temporary `client-new-thread:` ID while the active Browser Use turn belongs to the real thread. This may be a stale route/owner alias or teardown bug in the Windows IAB lifecycle path. ## Expected behavior `browser.tabs.finalize(...)` should close/release only the requested Browser Use tabs. Codex Desktop, app-server, unrelated browser tabs, and other running tasks must remain alive. ## Impact - All concurrent tasks are interrupted. - Long-running work must be manually resumed. - The failure looks like a user cancellation even though no cancel/interrupt was requested. - No diagnostic crash artifact is generated. Both interrupted task transcripts and repository working trees remained intact after relaunch; SQLite integrity checks passed. ## Workaround A durable local instruction now prevents agents on this build from calling `browser.tabs.finalize(...)` for the IAB backend and leaves IAB tabs open. Browser Use otherwise remains functional. No further whole-app exit has occurred since applying that workaround. ## Related issues - #24998 — similar Windows silent close after a task finishes, but without this deterministic `browser.tabs.finalize(...)` trigger - #23814 — related Windows browser/sidebar lifecycle churn and silent app/session closes I have retained the original local desktop logs and session transcripts. Full logs are not attached publicly because they may contain local paths, prompts, and environment metadata; targeted sanitized excerpts can be provided if maintainers request them.", "url": "https://github.com/openai/codex/issues/35210", "createdAt": "2026-07-24T16:19:44Z", "updatedAt": "2026-08-13T07:14:24Z", "timestamp": "2026-08-13T07:14:24Z", "metrics": { "reactions": 0, "comments": 11 }, "labels": [ "bug", "windows-os", "app", "browser" ], "author": "alex-sc7", "state": "open", "assignees": [] }, { "id": "github:openai/codex:issue:35234", "source": "github", "group": "coding-agent-infrastructure", "project": "openai/codex", "kind": "issue", "title": "Computer Use native pipe rejects signed in-app sender as unauthenticated on macOS 26.5.2", "text": "### What happened? Computer Use is installed and enabled in the official macOS desktop app, but even the read-only `list_apps` call fails after the native Computer Use service starts. After a full app quit and relaunch, the tool reports: ```text Sky Computer Use native pipe startup failed Caused by: Sky Computer Use native pipe is unavailable: Sky Computer Use native pipe closed before response ``` The freshly started `SkyComputerUseService` process remains running, but its unified logs repeat: ```text [com.apple.securityd:security_exception] MacOS error: -67062 [inc.software.app:Computer Use] Sender process is not authenticated ``` macOS resolves `-67062` as: ```text code object is not signed at all ``` However, the app, Computer Use helper, packaged Node runtime, and `node_repl` launcher all pass code-signature verification and are signed by OpenAI. ### Environment - macOS: 26.5.2 (25F84) - Architecture: arm64 / Apple Silicon - Desktop app path: `/Applications/ChatGPT.app` - App bundle identifier: `com.openai.codex` - App version: `26.721.31836` - App build: `5828` - Computer Use plugin: `computer-use@openai-bundled` version `1.0.1000502` - Managed helper: `$HOME/.codex/computer-use/Codex Computer Use.app` - Helper bundle identifier: `com.openai.sky.CUAService` ### Configuration state `codex features list` reports: ```text apps stable true computer_use stable true plugins stable true ``` Relevant config: ```toml [features] apps = true [plugins.\"computer-use@openai-bundled\"] enabled = true ``` The managed helper exists, is arm64, and is running. Its Unix socket also exists at: ```text $HOME/Library/Group Containers/2DC432GLL2.com.openai.sky.CUAService/IPC/computeruse.sock ``` ### Signature verification The managed Computer Use app passes: ```text codesign --verify --deep --strict spctl -a -vvv -t execute ``` Relevant result: ```text accepted source=Notarized Developer ID origin=Developer ID Application: OpenAI OpCo, LLC (2DC432GLL2) TeamIdentifier=2DC432GLL2 ``` The packaged runtime binaries also pass `codesign --verify --strict`: ```text /Applications/ChatGPT.app/Contents/Resources/cua_node/bin/node /Applications/ChatGPT.app/Contents/Resources/cua_node/bin/node_repl ``` Both report: ```text Authority=Developer ID Application: OpenAI OpCo, LLC (2DC432GLL2) TeamIdentifier=2DC432GLL2 ``` No `SkyComputerUseClient` or `SkyComputerUseService` crash report is created. ### Steps to reproduce 1. Open the official `/Applications/ChatGPT.app` and select Codex. 2. Ensure the bundled Computer Use plugin is installed and enabled. 3. Fully quit the desktop app with Cmd+Q. 4. Relaunch it. 5. In a Codex thread, ask Computer Use to run the read-only `list_apps` operation or inspect Finder. 6. Observe `Sky Computer Use native pipe startup failed`. 7. Inspect unified logs for `SkyComputerUseService`; observe `MacOS error: -67062` and `Sender process is not authenticated`. ### Expected behavior The signed Computer Use client launched from the official signed desktop app should authenticate to `SkyComputerUseService`, complete the native-pipe handshake, and return the app list. ### Installation/update source The desktop app was originally installed declaratively through `nix-darwin` / `nix-homebrew` with the Homebrew cask: ```nix homebrew.casks = [ \"codex-app\" ]; ``` Current local package/application state: ```text brew list --cask --versions codex-app codex-app 26.623.141536 brew list --cask --versions chatgpt # not installed /Applications/Codex.app # absent /Applications/ChatGPT.app # present, version 26.721.31836 ``` Homebrew now reports `codex-app` as deprecated/discontinued upstream and recommends the replacement cask `chatgpt`. The Homebrew receipt is therefore older than the active `ChatGPT.app`; the exact update/migration mechanism was not confirmed. The Nix configuration also installs the `codex` CLI from nixpkgs, which resolves on the shell PATH outside the app. However, this reproduction occurs inside the official desktop app and uses its packaged runtime under `/Applications/ChatGPT.app/Contents/Resources/`, not the Nix CLI. ### Additional context This appears related to: - #18507 — same `Sender process is not authenticated` symptom, but reported from the CLI. - #19544 — Homebrew CLI fails while the app-bundled CLI succeeds. - #21200 — launch-constraint/signature failure outside the app process tree. This report is distinct because it reproduces from the current official desktop app process tree, not from Homebrew, an ACP adapter, or another third-party launcher. The app is now located at `/Applications/ChatGPT.app`, while its bundle identifier remains `com.openai.codex`.", "url": "https://github.com/openai/codex/issues/35234", "createdAt": "2026-07-24T18:57:21Z", "updatedAt": "2026-08-13T17:54:53Z", "timestamp": "2026-08-13T17:54:53Z", "metrics": { "reactions": 0, "comments": 2 }, "labels": [ "bug", "auth", "app", "computer-use" ], "author": "Pape45", "state": "open", "assignees": [], "change": "new" }, { "id": "github:openai/codex:issue:35237", "source": "github", "group": "coding-agent-infrastructure", "project": "openai/codex", "kind": "issue", "title": "Codex will not enter Plan Mode", "text": "### What version of Codex CLI is running? codex-cli 0.145.0 ### What subscription do you have? Max ($100/mo plan) ### Which model were you using? gpt-5.6-Sol (Max) ### What platform is your computer? Linux 6.18.33.2-microsoft-standard-WSL2 x86_64 x86_64 ### What terminal emulator and version are you using (if applicable)? tmux inside Windows Terminal (WSL) ### Codex doctor report ```json { \"schemaVersion\": 1, \"generatedAt\": \"1784921895s since unix epoch\", \"overallStatus\": \"warning\", \"codexVersion\": \"0.145.0\", \"checks\": { \"app_server.status\": { \"id\": \"app_server.status\", \"category\": \"app-server\", \"status\": \"warning\", \"summary\": \"background server socket is stale or unreachable\", \"details\": { \"app-server version\": \"unavailable (failed to connect to control socket)\", \"control socket\": \"/home/tyler/.codex/app-server-control/app-server-control.sock\", \"daemon state dir\": \"/home/tyler/.codex/app-server-daemon\", \"mode\": \"persistent\", \"pid file\": \"/home/tyler/.codex/app-server-daemon/app-server.pid (missing)\", \"settings\": \"/home/tyler/.codex/app-server-daemon/settings.json (file)\", \"status\": \"stale or unreachable\", \"update-loop pid file\": \"/home/tyler/.codex/app-server-daemon/app-server-updater.pid (file)\" }, \"remediation\": \"Run codex app-server daemon version for more details.\", \"durationMs\": 1 }, \"auth.credentials\": { \"id\": \"auth.credentials\", \"category\": \"auth\", \"status\": \"ok\", \"summary\": \"auth is configured\", \"details\": { \"auth file\": \"/home/tyler/.codex/auth.json\", \"auth storage mode\": \"File\", \"stored API key\": \"false\", \"stored ChatGPT tokens\": \"true\", \"stored agent identity\": \"false\", \"stored auth mode\": \"chatgpt\" }, \"remediation\": null, \"durationMs\": 0 }, \"config.load\": { \"id\": \"config.load\", \"category\": \"config\", \"status\": \"ok\", \"summary\": \"config loaded\", \"details\": { \"CODEX_HOME\": \"/home/tyler/.codex\", \"config.toml\": \"/home/tyler/.codex/config.toml\", \"config.toml parse\": \"ok\", \"cwd\": \"/home/tyler/build-pipeline\", \"enabled feature flags\": \"shell_tool, unified_exec, shell_snapshot, code_mode_host, terminal_resize_reflow, sqlite, hooks, enable_request_compression, multi_agent, apps, tool_search_always_defer_mcp_tools, tool_suggest, plugins, in_app_browser, browser_use, browser_use_full_cdp_access, browser_use_external, computer_use, remote_plugin, plugin_sharing, image_generation, resize_all_images, skill_mcp_dependency_install, skill_search, mentions_v2, steer, guardian_approval, goals, collaboration_modes, tool_call_mcp_elicitation, auth_elicitation, personality, fast_mode, tui_app_server, remote_compaction_v2, workspace_dependencies\", \"feature flag overrides\": \"none\", \"feature flags enabled\": \"36\", \"log dir\": \"/home/tyler/.codex/log\", \"mcp servers\": \"1\", \"model\": \"gpt-5.6-sol\", \"model provider\": \"openai\", \"sqlite home\": \"/home/tyler/.codex\" }, \"remediation\": null, \"durationMs\": 0 }, \"git.environment\": { \"id\": \"git.environment\", \"category\": \"git\", \"status\": \"ok\", \"summary\": \"git version 2.43.0\", \"details\": { \".git entry\": \"directory\", \"PATH git #1\": \"/usr/bin/git\", \"PATH git entries\": \"1\", \"git branch\": \"master\", \"git build options\": \"git version 2.43.0; cpu: x86_64; no commit associated with this build; sizeof-long: 8; sizeof-size_t: 8; shell-path: /bin/sh\", \"git exec path\": \"/usr/lib/git-core\", \"git version\": \"git version 2.43.0\", \"repo detected\": \"true\", \"repo root\": \"/home/tyler/build-pipeline\", \"selected git\": \"/usr/bin/git\" }, \"remediation\": null, \"durationMs\": 22 }, \"installation\": { \"id\": \"installation\", \"category\": \"install\", \"status\": \"ok\", \"summary\": \"installation looks consistent\", \"details\": { \"PATH codex #1\": \"/home/tyler/.local/bin/codex\", \"PATH codex #2\": \"/home/tyler/.local/bin/codex\", \"PATH codex #3\": \"/home/tyler/.local/bin/codex\", \"PATH codex #4\": \"/home/tyler/.local/bin/codex\", \"PATH codex entries\": \"4\", \"current executable\": \"/home/tyler/.codex/packages/standalone/releases/0.145.0-x86_64-unknown-linux-musl/bin/codex\", \"install context\": \"standalone (unix, package /home/tyler/.codex/packages/standalone/releases/0.145.0-x86_64-unknown-linux-musl, bin /home/tyler/.codex/packages/standalone/releases/0.145.0-x86_64-unknown-linux-musl/bin, resources /home/tyler/.codex/packages/standalone/releases/0.145.0-x86_64-unknown-linux-musl/codex-resources, path /home/tyler/.codex/packages/standalone/releases/0.145.0-x86_64-unknown-linux-musl/codex-path)\", \"managed by bun\": \"false\", \"managed by npm\": \"false\", \"managed by pnpm\": \"false\", \"managed package root\": \"not set\" }, \"remediation\": null, \"durationMs\": 6 }, \"mcp.config\": { \"id\": \"mcp.config\", \"category\": \"mcp\", \"status\": \"ok\", \"summary\": \"MCP configuration is locally consistent\", \"details\": { \"configured servers\": \"1\", \"disabled servers\": \"0\", \"stdio servers\": \"1\" }, \"remediation\": null, \"durationMs\": 0 }, \"network.env\": { \"id\": \"network.env\", \"category\": \"network\", \"status\": \"ok\", \"summary\": \"network-related environment looks readable\", \"details\": { \"proxy env vars\": \"none\" }, \"remediation\": null, \"durationMs\": 0 }, \"network.provider_reachability\": { \"id\": \"network.provider_reachability\", \"category\": \"reachability\", \"status\": \"ok\", \"summary\": \"active provider endpoints are reachable over HTTP\", \"details\": { \"ChatGPT base URL\": \"https://chatgpt.com/backend-api/ reachable (HTTP 403)\", \"reachability mode\": \"ChatGPT auth\" }, \"remediation\": null, \"durationMs\": 44 }, \"network.websocket_reachability\": { \"id\": \"network.websocket_reachability\", \"category\": \"websocket\", \"status\": \"ok\", \"summary\": \"Responses WebSocket handshake succeeded\", \"details\": { \"DNS\": \"2 IPv4, 2 IPv6, first IPv4\", \"auth mode\": \"chatgpt\", \"connect timeout\": \"15000 ms\", \"endpoint\": \"wss://chatgpt.com/backend-api/\", \"handshake result\": \"HTTP 101 Switching Protocols\", \"model provider\": \"openai\", \"models etag present\": \"true\", \"provider name\": \"OpenAI\", \"proxy env vars\": \"none\", \"reasoning header\": \"false\", \"server model present\": \"false\", \"supports websockets\": \"true\", \"wire API\": \"responses\" }, \"remediation\": null, \"durationMs\": 444 }, \"runtime.provenance\": { \"id\": \"runtime.provenance\", \"category\": \"runtime\", \"status\": \"ok\", \"summary\": \"running standalone on linux-x86_64\", \"details\": { \"commit\": \"unknown\", \"current executable\": \"/home/tyler/.codex/packages/standalone/releases/0.145.0-x86_64-unknown-linux-musl/bin/codex\", \"install method\": \"standalone (unix, package /home/tyler/.codex/packages/standalone/releases/0.145.0-x86_64-unknown-linux-musl, bin /home/tyler/.codex/packages/standalone/releases/0.145.0-x86_64-unknown-linux-musl/bin, resources /home/tyler/.codex/packages/standalone/releases/0.145.0-x86_64-unknown-linux-musl/codex-resources, path /home/tyler/.codex/packages/standalone/releases/0.145.0-x86_64-unknown-linux-musl/codex-path)\", \"platform\": \"linux-x86_64\", \"version\": \"0.145.0\" }, \"remediation\": null, \"durationMs\": 0 }, \"runtime.search\": { \"id\": \"runtime.search\", \"category\": \"search\", \"status\": \"ok\", \"summary\": \"search is OK (bundled)\", \"details\": { \"search command\": \"/home/tyler/.codex/packages/standalone/releases/0.145.0-x86_64-unknown-linux-musl/codex-path/rg\", \"search command readiness\": \"file exists\", \"search provider\": \"bundled\" }, \"remediation\": null, \"durationMs\": 0 }, \"sandbox.helpers\": { \"id\": \"sandbox.helpers\", \"category\": \"sandbox\", \"status\": \"ok\", \"summary\": \"sandbox configuration is readable\", \"details\": { \"approval policy\": \"OnRequest\", \"codex-linux-sandbox helper\": \"/home/tyler/.codex/tmp/arg0/codex-arg0CCpsF9/codex-linux-sandbox\", \"execve wrapper helper\": \"/home/tyler/.codex/tmp/arg0/codex-arg0CCpsF9/codex-execve-wrapper\", \"filesystem sandbox\": \"restricted\", \"network sandbox\": \"restricted\" }, \"remediation\": null, \"durationMs\": 0 }, \"state.paths\": { \"id\": \"state.paths\", \"category\": \"state\", \"status\": \"ok\", \"summary\": \"state paths and databases are inspectable\", \"details\": { \"CODEX_HOME\": \"/home/tyler/.codex (dir)\", \"active rollout files\": \"268 files, 273461298 total bytes, 1020377 average bytes\", \"archived rollout files\": \"0 files, 0 total bytes, 0 average bytes\", \"goals DB\": \"/home/tyler/.codex/goals_1.sqlite (file)\", \"goals DB integrity\": \"ok\", \"log DB\": \"/home/tyler/.codex/logs_2.sqlite (file)\", \"log DB integrity\": \"ok\", \"log dir\": \"/home/tyler/.codex/log (dir)\", \"memories DB\": \"/home/tyler/.codex/memories_1.sqlite (file)\", \"memories DB integrity\": \"ok\", \"sqlite home\": \"/home/tyler/.codex (dir)\", \"standalone release cache\": \"1 entries in /home/tyler/.codex/packages/standalone/releases\", \"state DB\": \"/home/tyler/.codex/state_5.sqlite (file)\", \"state DB integrity\": \"ok\", \"thread history DB\": \"/home/tyler/.codex/thread_history_1.sqlite (missing)\", \"thread history DB integrity\": \"skipped (missing)\" }, \"remediation\": null, \"durationMs\": 2281 }, \"state.rollout_db_parity\": { \"id\": \"state.rollout_db_parity\", \"category\": \"threads\", \"status\": \"ok\", \"summary\": \"rollout files and state DB thread inventory agree\", \"details\": { \"default model provider\": \"openai\", \"rollout DB active files\": \"268\", \"rollout DB active rows\": \"268\", \"rollout DB archive mismatches\": \"0\", \"rollout DB archived files\": \"0\", \"rollout DB archived rows\": \"0\", \"rollout DB duplicate DB paths\": \"0\", \"rollout DB duplicate rollout thread ids\": \"0\", \"rollout DB malformed file names\": \"0\", \"rollout DB missing active rows\": \"0\", \"rollout DB missing archived rows\": \"0\", \"rollout DB model providers\": \"openai=267, openai_http=1\", \"rollout DB rows\": \"268\", \"rollout DB scan cap reached\": \"false\", \"rollout DB scan errors\": \"0\", \"rollout DB sources\": \"subagent:other=118, cli=117, subagent:thread_spawn=20, vscode=13\", \"rollout DB stale rows\": \"0\" }, \"remediation\": null, \"durationMs\": 94 }, \"system.environment\": { \"id\": \"system.environment\", \"category\": \"system\", \"status\": \"ok\", \"summary\": \"OS language C\", \"details\": { \"EDITOR\": \"not set\", \"LANG\": \"C.UTF-8\", \"VISUAL\": \"not set\", \"os\": \"Ubuntu 24.4.0 (noble) [64-bit]\", \"os language\": \"C\", \"os type\": \"Ubuntu\", \"os version\": \"24.4.0\" }, \"remediation\": null, \"durationMs\": 4 }, \"terminal.env\": { \"id\": \"terminal.env\", \"category\": \"terminal\", \"status\": \"ok\", \"summary\": \"terminal metadata was detected\", \"details\": { \"TERM\": \"xterm-256color\", \"color output\": \"enabled\", \"effective locale\": \"C.UTF-8\", \"multiplexer\": \"tmux 3.4\", \"stderr is terminal\": \"true\", \"stdin is terminal\": \"true\", \"stdout is terminal\": \"true\", \"terminal\": \"unknown\", \"terminal size\": \"139x30\", \"tmux allow-passthrough\": \"off\", \"tmux client termname\": \"xterm-256color\", \"tmux extended-keys\": \"off\", \"tmux focus-events\": \"off\", \"tmux set-clipboard\": \"external\", \"tmux xterm-keys\": \"on\" }, \"remediation\": null, \"durationMs\": 12 }, \"terminal.title\": { \"id\": \"terminal.title\", \"category\": \"title\", \"status\": \"ok\", \"summary\": \"terminal title default\", \"details\": { \"terminal title activity\": \"true\", \"terminal title items\": \"activity, project-name\", \"terminal title project source\": \"git repo root\", \"terminal title project value\": \"build-pipeline\", \"terminal title source\": \"default\" }, \"remediation\": null, \"durationMs\": 1 }, \"updates.status\": { \"id\": \"updates.status\", \"category\": \"updates\", \"status\": \"ok\", \"summary\": \"update configuration is locally consistent\", \"details\": { \"cached latest version\": \"0.145.0\", \"check for update on startup\": \"true\", \"dismissed version\": \"0.129.0\", \"last checked at\": \"2026-07-24T18:46:01.551510619Z\", \"latest version\": \"0.145.0\", \"latest version status\": \"current version is not older\", \"update action\": \"standalone installer\", \"version cache\": \"/home/tyler/.codex/version.json\" }, \"remediation\": null, \"durationMs\": 265 } } } ``` ### What issue are you seeing? Codex CLI does not properly enter Plan mode. This has occurred two times in the past day and a half. I've discovered that this is the case after Codex proceeds to begin non-planning work (editing files, implementing changes etc., and not asking questions or producing a plan) despite being set to plan mode. Entering Plan Mode via Shift+Tab shortcut or `/plan` causes the purple \"Plan mode\" text to appear at the bottom right of the terminal session, and the agent's tools are correctly set, but the agent is told it is still in Default mode. > > **Is plan mode not working for you? You typicaly ask clarifying questions and build an actual plan. Diagnose what went wrong here and then** > **we'll continue** > > > • Yes—there was a mode mismatch, and I handled it poorly. > > The runtime instructions told me I was in Default mode. A request containing “make a plan” does not itself activate Plan mode. I > attempted to use the planning checklist anyway, and the tool rejected it with the contradictory message that it was “not allowed in Plan > mode.” That suggests Plan-mode state was not propagated consistently. > > I should have surfaced that mismatch immediately. Instead, I continued in Default mode, performed the audit, made several assumptions, > and presented a provisional architecture as though it were an agreed plan. > > I also skipped important clarification questions, particularly: > > - Whether every teammate runs both controller and worker, or a shared controller targets personal workers. > - Whether controller and worker may be the same machine. > - Which operating systems must be supported. > - Whether workers must reproduce Altair’s exact toolchain or may use compatible variants. > - Whether dashboards remain local or are exposed to the team network. > > So the audit evidence remains useful, but the “implementation plan” should be treated as a draft proposal—not the proper Plan-mode > result. > > When we continue, I’ll first confirm Plan mode is actually active, ask the consequential questions, and then produce a concrete > implementation plan with scope, file-level changes, migration compatibility, verification, and explicit non-goals. > > **Hmm. Do the instructions still inform you that you're in Default mode?** > > > • Yes. The active runtime instructions still identify the collaboration mode as Default, and I have not received a subsequent developer > instruction switching it to Plan mode. Your UI may therefore be out of sync with the mode delivered to me. > > **Can you verify whether the tools and abilities you have access to match with plan mode or default mode? I'm gathering some info** > > > • I’ll run a non-destructive planning-tool capability probe. This distinguishes the instruction label I can see from the mode the tool > backend is actually enforcing. > > • The tooling currently behaves as Plan mode, despite the visible instructions still saying Default mode. > > Evidence: > > - request_user_input, described as Plan-mode-only, is exposed. > - I just invoked update_plan; the backend rejected it specifically because “TODO/checklist tool is not allowed in Plan mode.” > - Execution/editing tools are available in both modes, so they are not diagnostic. > > Therefore there is a split state: > > - Injected collaboration-mode instructions: Default > - Tool/backend mode enforcement: Plan > > My earlier answers reflected only the instruction layer. The backend probe shows your mode change did take effect somewhere, but the > collaboration-mode instruction was not refreshed accordingly. ### What steps can reproduce the bug? 1) Enter plan mode with Shift+Tab or `/plan` 2) Tell agent to audit something and make a plan to fix 3) Watch the agent not do plan-mode things, not make a plan, not ask questions ### What is the expected behavior? Actually engage in plan mode ### Additional information I had started this Codex conversion with the node.js-installed CLI application, and then continued it (and encountered this bug) after reinstalling Codex CLI via the bash script method.", "url": "https://github.com/openai/codex/issues/35237", "createdAt": "2026-07-24T19:41:13Z", "updatedAt": "2026-08-13T11:37:54Z", "timestamp": "2026-08-13T11:37:54Z", "metrics": { "reactions": 0, "comments": 4 }, "labels": [ "bug", "CLI", "plan" ], "author": "tylercasper", "state": "open", "assignees": [] }, { "id": "github:openai/codex:issue:35259", "source": "github", "group": "coding-agent-infrastructure", "project": "openai/codex", "kind": "issue", "title": "Codex Desktop repeatedly re-enters the model during wait/status polling, consuming substantial credits", "text": "## Summary During intentional Ultra and multi-agent work, Codex Desktop repeatedly re-entered the model merely to wait for agents or poll terminal status. In a corrected reset-to-49%-usage window, model turns whose only tool action was wait/status polling accounted for **19.8% of raw local token volume**. Ultra and multi-agent use were intentional. The suspected defect is not normal agent fan-out; it is repeated model inference during quiet coordination and process-wait intervals, often at 30- or 60-second cadence. Related reports exist, but this report adds current-build evidence, replay-safe accounting, a full usage-cycle window, tool-level decomposition, a representative long-running trace, and a public-rate-card estimate. ## Environment - ChatGPT Pro - macOS on Apple silicon - Codex Desktop 26.721.31836 (build 5828) - Incident runtime: codex-cli 0.146.0-alpha.3.1 - Mostly GPT-5.6 Sol ## What issue are you seeing? Long-running multi-agent tasks can generate hundreds of distinct model turns that do no substantive work beyond calling one of these tools: - `wait_agent` - `list_agents` - `write_stdin` - generic `wait` Each polling interval appears to re-enter the model, ingest a large cached conversation prefix, and then make another wait/status call. This can continue for hours while delegated work or a terminal process is still running. ## Corrected local evidence I analyzed local rollout telemetry from one complete weekly reset window, from the reset through the first observed 49% usage state. The parser: - excludes copied parent-history prefixes in child rollouts; - starts each child at its live `task_started` boundary; - ignores unchanged cumulative token snapshots; and - counts only genuine per-turn token deltas. Corrected window: - 10,586 genuine model turns - 1,382,757,012 raw local tokens - 43,668,351 uncached input tokens - 1,335,723,264 cached input tokens - 3,365,397 output tokens - 96.83% cached-input share - 94,241 copied-prefix token records excluded - 404 duplicate token snapshots excluded Tool-only wait/status turns: | Tool group | Turns | Raw local tokens | Uncached input | Cached input | Output | Share of all raw | |---|---:|---:|---:|---:|---:|---:| | `wait_agent` / `list_agents` only | 985 | 142,137,652 | 2,654,345 | 139,365,376 | 117,931 | 10.3% | | `write_stdin` / `wait` only | 983 | 131,423,068 | 1,319,437 | 130,028,544 | 75,087 | 9.5% | | Combined | 1,968 | 273,560,720 | 3,973,782 | 269,393,920 | 193,018 | **19.8%** | Using the current public GPT-5.6 Sol rate card, the combined wait/status subset corresponds to an estimated **3,948 credits**. This is a rate-card estimate from local telemetry, not a claim about the private subscription billing ledger. ## Representative long-running trace One child task ran for about 10 hours 55 minutes and contained: - 1,417 genuine model turns - 254 `wait_agent` calls - 31 `list_agents` calls - 316 `write_stdin` calls - 12 generic `wait` calls - 613 combined wait/status-only turns - about 93.17 million raw local tokens attributable to those wait/status turns The wait/status subset was about 45% of that child task's genuine raw token volume. Most agent waits requested only 30 or 60 seconds before another model-mediated poll. ## Steps to reproduce 1. Start an Ultra task that delegates a genuinely long-running child task. 2. Let the child run for at least 30-60 minutes while the parent or another child coordinates it. 3. Observe repeated `wait_agent`, `list_agents`, `write_stdin`, or generic `wait` calls during otherwise quiet intervals. 4. Inspect per-turn local token deltas, excluding copied child-history prefixes and unchanged cumulative snapshots. 5. Note that status-only polling repeatedly creates distinct model turns and reprocesses a large cached context. ## Expected behavior Waiting for an agent or terminal process should be event-driven, or handled by the harness without repeatedly invoking the model. The model should wake when: - the child or process produces meaningful new output; - the child completes or requires attention; - the user sends new input; or - a deliberately bounded, low-frequency checkpoint is required. ## Actual behavior Quiet wait intervals repeatedly invoke the model so it can issue another polling tool call. Large cached prefixes are charged through the public credit model even though the turns produce almost no substantive user-facing work. ## Why this is not ordinary Ultra fan-out Ultra and explicit multi-agent delegation were intentional, and their extra cost is expected. The anomalous subset here is narrower: nearly one-fifth of corrected raw token volume came from turns whose only action was waiting or checking status. The same corrected window attributed 68.1% of raw volume to Ultra and 58.7% to subagents. Those figures describe the chosen workload. This issue concerns the avoidable model-mediated polling inside that workload. ## Evidence boundary - These figures come from local rollout telemetry, not OpenAI's internal billing ledger. - Raw local token volume is not the same as subscription usage. - The credit figure is an estimate using the published model rate card. - Copied historical token records were explicitly excluded and are not claimed as billing events. - I found no evidence here of a silent quota reduction. - No private prompts, task identifiers, repository names, local paths, account details, or transcript content are included. ## Related reports - #34468 — parent chat polls child agents every minute - #33276 — wait-for-agents loop drained quota - #35108 — nested wait-agent polling - #13733 — terminal polling - #18394 — default wait timeout - #34361 — replay attribution work ## Suggested fix direction - Make agent and terminal waits event-driven inside the harness. - Avoid a fresh model call when no meaningful state has changed. - Coalesce repeated status checks and apply backoff for long-running work. - Surface wait/polling usage separately in diagnostics. - Add regression coverage asserting that unchanged wait state does not create repeated billable model turns.", "url": "https://github.com/openai/codex/issues/35259", "createdAt": "2026-07-24T23:11:07Z", "updatedAt": "2026-08-13T05:20:50Z", "timestamp": "2026-08-13T05:20:50Z", "metrics": { "reactions": 7, "comments": 13 }, "labels": [ "bug", "rate-limits", "tool-calls", "app", "subagent" ], "author": "dimasyankauskas", "state": "open", "assignees": [] }, { "id": "github:openai/codex:issue:35333", "source": "github", "group": "coding-agent-infrastructure", "project": "openai/codex", "kind": "issue", "title": "VS Code /ide shows IDE context enabled but sends no active file or selection", "text": "### What version of the IDE extension are you using? openai.chatgpt 26.721.41059 ### What subscription do you have? ChatGPT Pro 5x ### Which IDE are you using? Visual Studio Code 1.130.0 ### What platform is your computer? Microsoft Windows NT 10.0.26200.0 x64 (Windows 25H2, build 26200.8875) ### What issue are you seeing? Selecting **IDE context** from the `/ide` menu adds the gray IDE context indicator to the VS Code Codex composer, but messages sent while that indicator is present contain no active filename, selected text, or open-file IDE context. There is no visible error. A test message sent while VS Code showed **19 characters selected** received the response that no IDE-attached filename or selected text was supplied. The active temporary profile persisted `\"composer-auto-context-enabled\": true`, so the toggle is enabled; the failure occurs when collecting or injecting the IDE payload into the message. ### What steps can reproduce the bug? Feedback ID: 019f989d-64b5-77b0-ac59-180940968b7c ### What is the expected behavior? When **IDE context** is enabled, a message should include the active filename, current editor selection, open files, and other advertised IDE context. Codex should be able to report the selected file and text without searching the repository. ### Additional information ## Isolation and control results - Desktop ChatGPT/Codex app was fully closed and was not started after reboot. - Failure reproduces in an empty VS Code Temporary Profile with only the Codex extension installed and no custom settings. - Failure reproduces when the repository folder is opened directly, not through its `.code-workspace` file. - When opened through the previous `.code-workspace`, the IDE context indicator did not render and the persisted toggle remained false. When the folder was opened directly, the indicator rendered and the persisted toggle became true, but no IDE payload was sent. - Clicking the gray IDE context indicator removes/disables it; leaving it present when sending still produces no context. - The control command **Add to Codex Thread** successfully serialized a file and line reference: `d:\\repos\\main\\dt-site-svkt\\app0\\site0\\package.json (line 7)`. This suggests the basic editor attachment bridge can communicate with Codex while automatic IDE-context injection fails. - Workspace is on a healthy Windows Dev Drive using ReFS (`D:`), but the explicit file/line attachment control succeeds from that drive. - Separate clean-profile test thread: `codex://threads/019f98c6-ee77-77a3-8bd2-60b0e19268d3` - Feedback upload ID: `019f989d-64b5-77b0-ac59-180940968b7c` No raw logs are manually attached; the feedback upload includes the current session logs.", "url": "https://github.com/openai/codex/issues/35333", "createdAt": "2026-07-25T10:47:08Z", "updatedAt": "2026-08-12T21:27:15Z", "timestamp": "2026-08-12T21:27:15Z", "metrics": { "reactions": 3, "comments": 3 }, "labels": [ "bug", "windows-os", "extension" ], "author": "ralphwest1", "state": "open", "assignees": [] }, { "id": "github:openai/codex:issue:35419", "source": "github", "group": "coding-agent-infrastructure", "project": "openai/codex", "kind": "issue", "title": "VS Code IDE context auto-disables and selected text is not attached in WSL2", "text": "### What version of the IDE extension are you using? 26.721.41059 ### What subscription do you have? Plus ### Which IDE are you using? VS Code ### What platform is your computer? 6.18.33.2-microsoft-standard-WSL2 x86_64 x86_64 GNU/Linux ### What issue are you seeing? Automatic IDE context initially appears enabled in the VS Code Codex composer, but the IDE context indicator disappears after a short time. Messages sent afterward do not include the active file or selected text. Running `/ide-context` or reloading VS Code does not permanently fix it. The extension log reports: [Composer] failed to fetch ide-context error={} The persisted `composer-auto-context-enabled` state is then changed to false. This reproduced after: - restarting WSL - restarting Windows - uninstalling and reinstalling the Codex extension in WSL ### Steps to reproduce 1. Open a repository using VS Code Remote - WSL. 2. Open a normal file-backed editor. 3. Select several lines. 4. Open the Codex sidebar. 5. Enable `/ide-context`. 6. Wait briefly or send a message. 7. Observe that the IDE context indicator disappears. 8. Ask Codex to identify the selected lines. 9. Observe that no active-file or selection context is attached. ### Expected behavior The IDE context setting should remain enabled, and each message should include the active file, selected text, and open tabs. ### Actual behavior IDE context discovery fails, the setting is automatically disabled, and selected text is omitted. ### Additional diagnosis The VS Code editor-side provider itself is working: - A standalone Codex CLI running in the same WSL workspace with `/ide on` successfully receives the active file and exact selected text. - Therefore VS Code selection tracking and the IDE IPC socket are healthy. Inspection of the clean-installed extension bundle showed that: - the non-Electron/VS Code path can request IDE context with an empty `workspaceRoot`; - a discovery error automatically persists the IDE-context preference as disabled; - the Webview `clientCoordination` path fails even though the editor-side provider can return the selection. A local workaround that preserves the enabled preference and retrieves the selection directly through the VS Code host bridge restores IDE context without changing VS Code, WSL, authentication, or network configuration. This appears related to, but distinct from: - https://github.com/openai/codex/issues/24514 ### What steps can reproduce the bug? Feedback ID: 019f9bde-3cda-77f2-8730-84e17b1237a0 ### What is the expected behavior? When IDE context is enabled, it should remain enabled and visible in the Codex composer. Each message should automatically include the current active file, selected text, and open tabs. Reloading VS Code should preserve this setting, and transient IDE discovery failures should not disable it. ### Additional information I reproduced the issue on a clean installation before applying any local changes. As a diagnostic workaround, I modified the installed extension locally to: 1. Always pass the actual workspace root when requesting IDE context, instead of passing an empty string on the VS Code/non-Electron path. 2. Prevent a transient IDE discovery failure from automatically persisting `composer-auto-context-enabled` as disabled. 3. Bypass the failing `clientCoordination.getIdeContext()` Webview RPC and retrieve the current IDE context directly through a VS Code host bridge backed by the extension's existing editor-selection provider. After reloading VS Code, the Codex message correctly contained: - the active file path; - the exact selected lines; - the list of open tabs. This confirms that VS Code selection tracking and the editor-side provider were working, while the failure was in the extension's Webview/context transport path. This is only a local diagnostic workaround, not a proposed production patch. It modifies generated extension bundle files and will be overwritten by an extension update or reinstall.", "url": "https://github.com/openai/codex/issues/35419", "createdAt": "2026-07-26T02:06:21Z", "updatedAt": "2026-08-12T21:35:20Z", "timestamp": "2026-08-12T21:35:20Z", "metrics": { "reactions": 11, "comments": 6 }, "labels": [ "bug", "windows-os", "extension" ], "author": "thisinnocence", "state": "open", "assignees": [] }, { "id": "github:openai/codex:issue:35476", "source": "github", "group": "coding-agent-infrastructure", "project": "openai/codex", "kind": "issue", "title": "Windows Codex App: authenticated SMB/UNC workspaces fail in both sandbox modes", "text": "### What version of the Codex App are you using (From “About Codex” dialog)? 26.721.4979.0 ### What subscription do you have? ChatGPT Plus ### What platform is your computer? Microsoft Windows NT 10.0.26200.0 x64 / Windows 11 Pro ### What issue are you seeing? Codex Desktop cannot reliably access projects located on a normal authenticated SMB share through UNC paths. Example redacted writable roots: \\\\server.example.local\\domains\\PROJECT_A \\\\server.example.local\\domains\\PROJECT_B With: [windows] sandbox = \"elevated\" every sandboxed command fails before PowerShell starts. This also happens when the command is executed from a local TEMP directory because the sandbox setup refresh processes all configured UNC writable roots. setup_error.json contains: {\"code\":\"helper_unknown_error\",\"message\":\"setup refresh had errors\"} The sandbox log contains messages equivalent to: granting write ACE to \\\\?\\UNC\\server.example.local\\domains\\PROJECT_A for sandbox group and capability SID write ACE grant failed: SetNamedSecurityInfoW failed: 5 setup refresh completed with errors After changing the configuration to: [windows] sandbox = \"unelevated\" and restarting Codex, local sandboxed commands work. However, the allowed UNC repositories remain inaccessible. The following was verified from inside the unelevated sandbox: - The process runs under the same Windows user as the host. - DNS resolves the SMB server correctly. - TCP port 445 is reachable. - `net use` shows the mapped network share. - Windows Credential Manager contains the SMB credential. - `Get-Item` against the UNC path returns Access denied. - `git -C status` returns Access denied. - A requested UNC working directory is not used and PowerShell starts in its installation directory instead. - The internal apply_patch operation can create a new file on the UNC share, but immediately fails to read or update that same file with os error 5. Host PowerShell outside the Codex sandbox can access the same repositories normally. ### What steps can reproduce the bug? 1. On Windows 11, connect to an authenticated SMB share available through a UNC path. 2. Open a Codex Desktop project located on that share and configure the UNC directory as an allowed writable root. 3. Set: [windows] sandbox = \"elevated\" 4. Restart Codex and run any sandboxed PowerShell command. 5. Observe that sandbox setup refresh fails before the command starts with SetNamedSecurityInfoW error 5. 6. Run the same test with a local TEMP directory as the working directory. 7. Observe that setup still fails because all configured UNC writable roots are processed. 8. Change the configuration to: [windows] sandbox = \"unelevated\" 9. Restart Codex. 10. Verify that local sandboxed commands work. 11. Run Get-Item or git status against the explicitly allowed UNC project. 12. Observe Access denied. 13. Use apply_patch to create a file on the share and then attempt to update it. 14. Observe that creation succeeds but reading or updating the file fails. ### What is the expected behavior? An explicitly allowed authenticated UNC workspace should remain accessible in at least the unelevated sandbox, which derives its restricted token from the current Windows user. A failure to configure permissions for one UNC writable root should not prevent unrelated sandboxed commands from running from local directories. File operations should behave consistently: if the sandbox can create a file, it should be able to read and update that file. If authenticated SMB/UNC paths are not supported, Codex should detect them before setup and display a clear actionable message instead of the generic helper_unknown_error. ### Additional information Switching to the unelevated sandbox removes the repeated global setup-refresh failure, but UNC access still requires running commands outside the sandbox. This appears related to issue #25422, but differs because this is a normal authenticated SMB share rather than a Cryptomator virtual filesystem, and both elevated and unelevated sandbox modes are affected. Related issue: https://github.com/openai/codex/issues/25422 Feedback ID: 019f9dbb-8f86-7d01-8949-935b52c5b7c6", "url": "https://github.com/openai/codex/issues/35476", "createdAt": "2026-07-26T13:14:52Z", "updatedAt": "2026-08-13T16:04:23Z", "timestamp": "2026-08-13T16:04:23Z", "metrics": { "reactions": 0, "comments": 6 }, "labels": [ "bug", "windows-os", "sandbox", "app" ], "author": "SilverHandCZ", "state": "open", "assignees": [] }, { "id": "github:openai/codex:issue:35746", "source": "github", "group": "coding-agent-infrastructure", "project": "openai/codex", "kind": "issue", "title": "Paginated history drops valid flattened rollout records and reuses ordinals", "text": "### What version of Codex CLI is running? Observed on `0.146.0-alpha.10.1`. The affected source paths remain unchanged in `rust-v0.146.0-alpha.14`. ### What platform is your computer? Linux x86_64. ### What issue are you seeing? Paginated rollout history has inconsistent `RolloutLine` decoding. Some readers deserialize JSON directly into `RolloutLine`, while the canonical loader first parses into `serde_json::Value` and then calls `serde_json::from_value::`. A serialized `RolloutLine::EventMsg(EventMsg::TokenCount(...))` containing populated rate-limit and credit data is valid JSON and succeeds through the value-first path, but direct `serde_json::from_str::` / `serde_json::from_slice::` rejects it. Two paginated-history readers currently use the direct path: - `codex-rs/rollout/src/ordinal.rs`: `scan_next::()` - `codex-rs/thread-store/src/local/thread_history_materialization.rs`: `serde_json::from_slice(line_bytes)` This produces two related failures: 1. Resume ordinal discovery silently skips the valid final record, steps back to an earlier ordinal, and can append a new record with an already-used ordinal. 2. SQLite history projection silently skips the valid record while advancing its byte offset beyond it, leaving the materialized projection behind the canonical JSONL permanently. Once affected, catch-up can begin with one replayed boundary ordinal equal to `projection_state.next_ordinal - 1`; rejecting that boundary prevents the remaining valid suffix from materializing. ### What steps can reproduce the bug? Add a focused test that serializes a paginated `RolloutLine` containing a token-count event with rate-limit and credit fields: ```rust let encoded = serde_json::to_string(&RolloutLine { timestamp: \"2026-07-09T00:00:05Z\".to_string(), ordinal: Some(5), item: RolloutItem::EventMsg(EventMsg::TokenCount(TokenCountEvent { info: Some(TokenUsageInfo::full_context_window(1_000)), rate_limits: Some(RateLimitSnapshot { limit_id: Some(\"limit-1\".to_string()), limit_name: None, primary: Some(RateLimitWindow { used_percent: 1.0, window_minutes: Some(60), resets_at: Some(1), }), secondary: None, credits: Some(CreditsSnapshot { has_credits: true, unlimited: false, balance: Some(\"1\".to_string()), }), individual_limit: None, spend_control_reached: None, plan_type: None, rate_limit_reached_type: None, }), })), })?; assert!(serde_json::from_str::(&encoded).is_err()); assert!( serde_json::from_str(&encoded) .and_then(serde_json::from_value::) .is_ok() ); ``` Then: 1. Append that record as the final line of a paginated rollout and resume it. Ordinal discovery ignores ordinal `5`. 2. Materialize the same rollout into the thread-history SQLite projection. The line is rejected, but the stored byte offset advances past it. ### What is the expected behavior? Every rollout reader should use the same value-first decoding semantics as the canonical loader. Resume should continue after the real final ordinal, and SQLite materialization should project every valid canonical record. For projections already affected by the old decoder, narrowly accepting and skipping one replayed first boundary ordinal (`next_ordinal - 1`) allows the remaining suffix to catch up without rewriting canonical JSONL. ### Additional information `rust-v0.146.0-alpha.14` changes nearby thread-list behavior for missing rollout paths, but `ordinal.rs` and `thread_history_materialization.rs` still use direct `RolloutLine` deserialization.", "url": "https://github.com/openai/codex/issues/35746", "createdAt": "2026-07-28T09:51:31Z", "updatedAt": "2026-08-13T14:19:00Z", "timestamp": "2026-08-13T14:19:00Z", "metrics": { "reactions": 0, "comments": 7 }, "labels": [ "bug", "CLI", "session" ], "author": "Tsury", "state": "open", "assignees": [] }, { "id": "github:openai/codex:issue:35823", "source": "github", "group": "coding-agent-infrastructure", "project": "openai/codex", "kind": "issue", "title": "logs_2.sqlite never reclaims freed pages: auto_vacuum=INCREMENTAL is set but never run, so the file grows monotonically despite working 10-day retention", "text": "### What version of the Codex App are you using (From “About Codex” dialog)? 1.2026.190.0 (MSIX OpenAI.ChatGPT-Desktop_1.2026.190.0_x64__2p2nqsd0c76g0) ### What subscription do you have? Pro $100 ### What platform is your computer? Microsoft Windows NT 10.0.26100.0 x64 (Windows 11 Home Single Language) ### What issue are you seeing? `~/.codex/logs_2.sqlite` grows without bound on a normal desktop profile **even though row retention is working correctly**. The row count is at steady state (~10 days of rows), but the file on disk keeps climbing, because pages freed by the retention DELETE go to the SQLite freelist and are never returned to the OS. The DB is created with `auto_vacuum = 2` (INCREMENTAL), but nothing ever runs `PRAGMA incremental_vacuum`. `run_logs_startup_maintenance()` deletes rows older than the retention window and then runs `PRAGMA wal_checkpoint(PASSIVE)` — neither of which shrinks the main DB file. So retention bounds *rows* but not *bytes*. Measured on this machine (Windows 11, Codex Desktop 1.2026.190.0), on an offline copy of the DB: | metric | value | |---|---| | `logs_2.sqlite` | 579,276,800 bytes (552 MiB) | | `logs_2.sqlite-wal` | 4.6 MiB | | `page_count` | 141,425 (4096-byte pages) | | `freelist_count` | **37,128 — 26% of the file is dead space** | | `auto_vacuum` | 2 (INCREMENTAL — never invoked) | | rows in `logs` | 253,043 | | `SUM(estimated_bytes)` | ~267 MB of actual log content | | `ts` span | 1784402440 → 1785266499 (exactly 10.0 days — retention *is* working) | ~267 MB of live content is occupying a 552 MiB file. **Growth rate.** I compacted this same DB with `VACUUM INTO` on 2026-07-17: 1.38 GB → 270 MB, zero rows lost. **Eleven days later it is back to 552 MiB** — roughly 25 MB/day of permanent, unreclaimed growth, with the row count flat. Left alone it returns to >1 GB in about a month, every month, on a machine that is only running the app normally. Level distribution over that same 10-day window (the volume amplifier, already tracked in #29674 / #31542 / #31111 — this issue is about the *reclamation* half): | level | rows | est. bytes | |---|---|---| | TRACE | 136,468 | 130.7 MB | | INFO | 56,841 | 69.3 MB | | DEBUG | 54,048 | 63.8 MB | | WARN | 5,511 | 3.2 MB | | ERROR | 175 | 0.1 MB | TRACE is 54% of rows and 49% of logged bytes, at default settings with no debug flag enabled. ### What steps can reproduce the bug? 1. Run Codex Desktop normally for several weeks on Windows — default config, no debug flag, `RUST_LOG` unset. 2. Wait until age-based retention is actively deleting (i.e. the oldest row is ~10 days old). 3. Copy `~/.codex/logs_2.sqlite`, `-wal` and `-shm` to a scratch directory. **Do not open the live DB** — it is in WAL mode under a running app; inspect the copy only. 4. Inspect the copy: ```python import sqlite3 c = sqlite3.connect(\"logs_2.sqlite\") # the COPY q = lambda s: c.execute(s).fetchall() print(\"page_count \", q(\"PRAGMA page_count\")) print(\"freelist \", q(\"PRAGMA freelist_count\")) print(\"auto_vacuum \", q(\"PRAGMA auto_vacuum\")) print(\"rows \", q(\"SELECT COUNT(*) FROM logs\")) print(\"live bytes \", q(\"SELECT SUM(estimated_bytes) FROM logs\")) print(\"ts span \", q(\"SELECT MIN(ts), MAX(ts) FROM logs\")) print(\"levels \", q(\"SELECT level, COUNT(*) FROM logs GROUP BY level\")) ``` 5. Repeat over days/weeks. `COUNT(*)` and the `ts` span stay flat at the retention window, but `page_count` and `freelist_count` only ever go up. The file never shrinks, at any point in the app lifecycle — launch, quit, idle, or restart. To see the reclaimable amount directly: `VACUUM INTO 'compact.sqlite'` on the copy. Here that produced a 270 MB file from a 552 MiB source with an identical row count. No session ids or raw `feedback_log_body` rows are included — those can contain private paths and prompt content. All figures above are aggregates. ### What is the expected behavior? Retention should bound the log DB **on disk**, not just the row count. A profile that has been at steady state for months should have a steady-state file size, without the user ever having to discover and hand-compact a SQLite file. Any one of these would fix it, in increasing order of effort: 1. **Call `PRAGMA incremental_vacuum` after the retention DELETE** in `run_logs_startup_maintenance()`. `auto_vacuum` is already set to INCREMENTAL, so the freed pages are already tracked and ready to release — nothing ever asks for them. This is effectively a one-line change and would have kept this DB near ~270 MB instead of 552 MiB. 2. Add a **byte cap** alongside the age cap, and run a full `VACUUM` when the file exceeds it — off the hot startup path, since a large-DB `VACUUM` at launch would just trade this bug for #27741 / #30517. 3. Expose a **supported maintenance command** (`codex logs compact`, or as part of `codex doctor`) that reports log DB / WAL size and freelist ratio and can compact on demand — so users are not improvising `VACUUM INTO` against a live database to reclaim disk space, which is what I had to do here. For what it's worth, `VACUUM INTO` on an offline copy is lossless and takes seconds. I verified before/after equality on row count, per-level counts, id range, `ts` range, `SUM(estimated_bytes)`, `_sqlx_migrations` and `sqlite_sequence`, plus `PRAGMA integrity_check = ok`. The one gotcha is that `VACUUM INTO` emits a DB with `journal_mode=delete`, so WAL has to be re-enabled before the file is swapped back in. ### Additional information **Scope.** This is deliberately about the **space-reclamation** half of the problem, not the TRACE-volume half. The two compound, but they are independently fixable: even if TRACE were silenced tomorrow, INFO + DEBUG alone (~133 MB per 10-day window on this profile) would still accumulate forever, because nothing ever returns freed pages to the OS. Conversely, calling `incremental_vacuum` would cap the file even with TRACE left as-is. **Related / overlapping issues** (I searched before filing): - #30431 — umbrella: \"bound and compact logs_2.sqlite\". That issue asks for the *policy* (byte caps, a compact command); this one names the *specific mechanism* — `auto_vacuum=INCREMENTAL` set but `incremental_vacuum` never called — and the minimal fix. Happy to have this folded in as a comment there if maintainers prefer. - #16270 — the same unbounded-growth shape on the older `logs_1.sqlite` / `state_5.sqlite`, closed as completed; the reclamation behaviour appears to have regressed or was never applied to `logs_2.sqlite`. - TRACE volume: #29674, #31542, #31111, #30236, #30780. - Large-DB symptoms: #28997 (WAL growth), #27741 (app-server SQLite pool times out at startup), #30517 (CLI stalls before the TUI prompt), #29237 (SIGTRAP above ~200 MB). **Environment** - Codex Desktop `1.2026.190.0`, MSIX `OpenAI.ChatGPT-Desktop_1.2026.190.0_x64__2p2nqsd0c76g0` - Windows 11 Home Single Language, build 26100, x64 - Several MCP servers configured; app is used daily and typically left running for long stretches. **Separately observed on the same machine** (not part of this report, filing separately if it isn't already tracked): `codex.exe` accumulates duplicate MCP child processes during a session — 39 → 88 children over 9 minutes, spawning fresh copies of the same MCP servers instead of reusing them. On this profile that is a larger performance drain than the log DB.", "url": "https://github.com/openai/codex/issues/35823", "createdAt": "2026-07-28T20:02:23Z", "updatedAt": "2026-08-13T05:55:58Z", "timestamp": "2026-08-13T05:55:58Z", "metrics": { "reactions": 1, "comments": 4 }, "labels": [ "bug", "windows-os", "app", "performance" ], "author": "ignaciomontenegroc", "state": "open", "assignees": [] }, { "id": "github:openai/codex:issue:35871", "source": "github", "group": "coding-agent-infrastructure", "project": "openai/codex", "kind": "issue", "title": "Windows sandbox: CreateProcessAsUserW fails with error 5 when the resolved shell is the MSIX (Store) build of pwsh", "text": "## Summary On Windows, the sandbox fails with `CreateProcessAsUserW failed: 5 (Access is denied.)` **whenever the resolved shell is the MSIX (Microsoft Store) build of PowerShell 7**. Windows refuses to launch a packaged (MSIX) binary under the restricted token the sandbox creates. This appears to be the underlying cause behind several open reports (openai/codex#26803, openai/codex#25436, openai/codex#26186, [#10090](), openai/codex#9062, and likely openai/codex#30047 / openai/codex#26896 where accounts were also involved). None of them identify the packaged-shell condition, which is why the failure looks environment-specific and unreproducible: **it depends solely on whether** `pwsh` **resolves to** `C:\\Program Files\\WindowsApps\\...`. ## Measurement Same machine, same session, 20 trials per shell. Counted on the presence of `CreateProcessAsUserW` in the output, **not** on the exit code (`cmd.exe` legitimately returns non-zero, which is misleading). | shell launched by the sandbox | failures | | -- | -- | | `pwsh.exe` — Store/MSIX (`C:\\Program Files\\WindowsApps\\Microsoft.PowerShell_7.6.4.0_x64__8wekyb3d8bbwe\\pwsh.exe`) | **20 / 20** | | `powershell.exe` 5.1 (`C:\\Windows\\System32\\WindowsPowerShell\\v1.0\\`) | 0 / 20 | | `cmd.exe` | 0 / 20 | | git bash | 0 / 20 | **End-to-end confirmation:** `codex exec` with the normal `PATH` resolves the MSIX `pwsh` and fails. The *same* `codex exec` with the `WindowsApps` entries removed from `PATH` falls back to PowerShell 5.1 and returns normally (exit 0, \\~720 ms). ## Error payload ``` windows sandbox: runner failed during SpawnChild: CreateProcessAsUserW failed: 5 (Access is denied.) | cwd=C:\\Users\\\\ | cmd=\"C:\\Program Files\\WindowsApps\\Microsoft.PowerShell_7.6.4.0_x64__8wekyb3d8bbwe\\pwsh.exe\" -NoProfile -Command \"...\" | env_u16_len=6928 | si_flags=256 | creation_flags=525312 (Windows error 5) ``` `creation_flags=525312` = `0x80400` = `CREATE_UNICODE_ENVIRONMENT | EXTENDED_STARTUPINFO_PRESENT`. ## Two red herrings we eliminated, in case they save someone time * **Environment block size.** `env_u16_len=6928` is **constant across all 20 failures**, and it is \\~5× below the documented 32,767 limit. An oversized block would also raise `ERROR_INVALID_PARAMETER` (87), not 5. Not the cause. * **\"Intermittent\" behaviour.** It looks intermittent but is **deterministic per command**: in our environment `echo hello` failed 20/20 while `Get-Content ` succeeded 20/20 — file reads evidently take a path that never reaches `SpawnChild`. Observers who tested different commands drew opposite conclusions from the same broken setup. Also ruled out on this machine: the `CodexSandboxOffline` / `CodexSandboxOnline` accounts both **exist and are enabled**, so this is not the missing-account variant. ## Environment * Windows 11 Pro, 10.0.26200 * `codex-cli` 0.144.3 * `~/.codex/config.toml`: `[windows] sandbox = \"elevated\"` ## Suggested fix When resolving the shell, **skip binaries under** `%ProgramFiles%\\WindowsApps` (or any MSIX-packaged executable) and fall back to `System32\\WindowsPowerShell\\v1.0\\powershell.exe`. A packaged binary cannot be started under a restricted token, so it can never work on the sandbox path. A clear error message would help too — `Access is denied` gives no hint that the *shell* is the problem. ## Workarounds for anyone hitting this now 1. Ensure a non-packaged `pwsh` precedes the Store one in `PATH`, or remove `WindowsApps` from the `PATH` handed to codex. 2. `[windows] sandbox = \"unelevated\"` in `~/.codex/config.toml` (documented fallback; not needed once the shell is non-packaged).", "url": "https://github.com/openai/codex/issues/35871", "createdAt": "2026-07-29T02:53:44Z", "updatedAt": "2026-08-13T15:29:12Z", "timestamp": "2026-08-13T15:29:12Z", "metrics": { "reactions": 3, "comments": 12 }, "labels": [ "bug", "windows-os", "sandbox", "exec", "CLI" ], "author": "dgx80", "state": "open", "assignees": [] }, { "id": "github:openai/codex:issue:35918", "source": "github", "group": "coding-agent-infrastructure", "project": "openai/codex", "kind": "issue", "title": "[Windows Desktop] Restore inline comments on Plan mode plans", "text": "## Summary Please restore inline comments/annotations on generated Plan mode plans in the Codex desktop app. ## What changed An earlier Codex workflow allowed me to select a specific part of a generated plan and attach a comment directly to that plan section. That made iterative planning feel much more precise: I could comment on one decision, constraint, or acceptance criterion without restating the whole plan. In the current Windows desktop experience, the native annotation affordance is no longer available on the plan itself. I can work around it by asking Codex to save the plan as Markdown, but that loses the native Plan mode presentation and makes the workflow less fluid. ## Requested behavior - Keep the generated plan as a first-class Plan mode item. - Allow selecting a plan heading or paragraph and attaching an inline comment. - Send the selected plan context together with the comment on the next turn. - Preserve the existing plan structure when Codex revises the plan. ## Why this matters This was an excellent interaction for design reviews, implementation specifications, and other work where the user wants to steer individual decisions before coding starts. It reduced ambiguity and made planning feel collaborative rather than like editing a long assistant message. Codex desktop on Windows. Exact app version is not visible from the current task.", "url": "https://github.com/openai/codex/issues/35918", "timestamp": "2026-08-12T12:43:51Z", "metrics": { "reactions": 0, "comments": 1 }, "labels": [ "enhancement", "windows-os", "app", "plan" ], "author": "chumdesign", "assignees": [], "change": "new" }, { "id": "github:openai/codex:issue:35939", "source": "github", "group": "coding-agent-infrastructure", "project": "openai/codex", "kind": "issue", "title": "Received usage restriction during Kaggle AI security competition – please lift", "text": "### What version of the Codex App are you using (From “About Codex” dialog)? Version 26.715.72028 ### What subscription do you have? ChatGPT Pro 5x ### What platform is your computer? _No response_ ### What issue are you seeing? I was participating in the Kaggle competition \"[AI Agent Security: Multi-Step Tool Attacks](https://www.kaggle.com/competitions/ai-agent-security-multi-step-tool-attacks)\" and received a security warning / usage restriction while using Codex. I believe this was triggered by the security-focused nature of the competition tasks. I no longer need to use Codex for this competition and have stopped using it for that purpose. Could you please lift the restriction on my account? I would appreciate it if you could review and remove the limitation. Thank you. ### What steps can reproduce the bug? Feedback ID: 019fa7f6-fe4d-7201-8a71-9e052098156e ### What is the expected behavior? _No response_ ### Additional information _No response_", "url": "https://github.com/openai/codex/issues/35939", "createdAt": "2026-07-29T11:39:07Z", "updatedAt": "2026-08-12T15:52:55Z", "timestamp": "2026-08-12T15:52:55Z", "metrics": { "reactions": 0, "comments": 1 }, "labels": [ "bug", "app", "safety-check" ], "author": "Oka00", "state": "open", "assignees": [], "change": "updated" }, { "id": "github:openai/codex:issue:36086", "source": "github", "group": "coding-agent-infrastructure", "project": "openai/codex", "kind": "issue", "title": "Codex (ChatGPT 5.6 Ultra) is giving reproducible, severe quality regressions since yesterday, this is not normal model variance", "text": "### What version of Codex CLI is running? 0.145.0 ### What subscription do you have? ChatGPT Pro ($200/month) ### Which model were you using? gpt-5.6-sol ultra ### What platform is your computer? Linux 6.6.87.2-microsoft-standard-WSL2 x86_64 (WSL2, Debian, Windows host) ### What terminal emulator and version are you using (if applicable)? Windows Terminal 1.24.11911.0 running WSL2/Debian ### Codex doctor report ```json overallStatus: ok codexVersion: 0.145.0 (latest available: 0.146.0) model: gpt-5.6-sol model provider: openai auth mode: chatgpt platform: linux-x86_64 (WSL2, Debian 13.0.0 trixie) network/provider reachability: ok All checks passed — no environment, auth, network, or config issues detected. Full JSON output available on request. ``` ### What issue are you seeing? I'm writing this as a Pro user paying $200/month and as someone with over 15 years of professional full-stack development experience, also working with deep learning models on a regular basis, because I think this deserves more than a vague \"it feels worse\" complaint. I want to document this properly. Since yesterday, the quality of code generation has collapsed to a level that is genuinely hard to believe coming from what's supposed to be the top tier model. I'm not talking about small inconsistencies or a model having an off moment on a tricky prompt. I'm talking about basic, previously reliable tasks failing outright, repeatedly, across completely unrelated parts of my stack. Beyond specific bugs (detailed in \"steps to reproduce\" below), the general frontend judgment has taken a hit too. Layout decisions, component structure, the kind of architectural reasoning that used to be handled competently is now inconsistent and careless in a way that feels categorically different, not just slightly worse. I want to explain why I don't think this is a normal fluctuation, because I know that's the first assumption people make. I work with LLMs professionally, so I understand what normal variance looks like: occasional stylistic differences, edge cases handled inconsistently, prompts needing slight rewording. What I'm describing here is not that. This is a simultaneous drop across multiple, completely unrelated task types, appearing from one day to the next, with no change on my end to prompting style, project structure, or anything else. Based on what I'm observing, my working hypothesis is that this pattern points toward something changing on your side, whether that's a quiet model swap, a quantized or distilled variant being routed to certain users or under certain load conditions, or some other backend decision that wasn't communicated. To be clear, this is a hypothesis on my part, not a claim of fact, and it's exactly why I'm asking for a direct answer below instead of assuming. ### What steps can reproduce the bug? Two concrete, reproducible cases from today, both on model gpt-5.6-sol (reasoning effort: Ultra): 1. Asked for a simple section component in Next.js using React, something this tool used to handle without any issue, and the output came back broken and incomplete. Not stylistically different, actually non-functional. 2. Styled a single button in SCSS and the change introduced regressions in selectors elsewhere in the stylesheet that had absolutely nothing to do with the request. That kind of scope leakage, where the model touches things outside the boundaries of what was asked, is the type of mistake I'd expect from a much smaller or less capable model, not from something marketed as your flagship offering. Environment: Codex CLI 0.145.0, WSL2/Debian 13.0.0, Windows Terminal, model gpt-5.6-sol. Full codex doctor output attached below confirms no environment, auth, network, or config issues — this is not a local setup problem. ### What is the expected behavior? Code generation quality consistent with the advertised top-tier model (\"ChatGPT 5.6 Ultra\" / gpt-5.6-sol, reasoning effort Ultra), matching the reliability I experienced with this same setup until yesterday: functional, scoped output for basic Next.js/React and SCSS tasks, without unrelated regressions or broken components. ### Additional information So here's what I actually want answered, and I'd like a specific response, not a generic support macro: Did anything change in terms of which model or variant is serving requests over the last 24 to 48 hours? A simple yes or no would already tell me a lot. If there are capacity constraints causing Pro tier traffic to be served by a reduced capability model at certain times or under certain conditions, that needs to be disclosed openly. I'm paying for a specific tier and I expect to know what I'm actually getting, not to find out through degraded output that something quietly changed underneath me. If this turns out to be a confirmed bug or regression that has nothing to do with any intentional change, I want an actual timeline, not \"we're aware and looking into it,\" which by now feels like a placeholder answer rather than a real update. To be clear about the stakes here, I use this tool for production level client work. At the quality level I'm seeing right now, it simply isn't usable for that, and that makes it very difficult to justify what I'm paying every month. I'd genuinely prefer to keep working with this tool, I've built a good part of my workflow around it, but staying silent on something this measurable and this sudden is exactly what pushes experienced users toward alternatives that are currently performing better for a fraction of the cost. I'm not looking for sympathy here, I'm looking for a direct, specific, and honest answer about what actually changed.", "url": "https://github.com/openai/codex/issues/36086", "createdAt": "2026-07-30T05:26:13Z", "updatedAt": "2026-08-13T02:58:31Z", "timestamp": "2026-08-13T02:58:31Z", "metrics": { "reactions": 0, "comments": 3 }, "labels": [ "bug", "model-behavior", "CLI" ], "author": "AndyAlvarezDev", "state": "open", "assignees": [] }, { "id": "github:openai/codex:issue:36179", "source": "github", "group": "coding-agent-infrastructure", "project": "openai/codex", "kind": "issue", "title": "Windows execpolicy cannot bind a bare PowerShell command to an approved launcher path", "text": "### What version of Codex CLI is running? `codex-cli 0.146.0` Reproduced with the official signed `codex-x86_64-pc-windows-msvc.exe` release asset for `rust-v0.146.0`. ### What subscription do you have? Pro ### Which model were you using? `gpt-5.6-sol` ### What platform is your computer? `Microsoft Windows NT 10.0.19045.0 x64` ### What terminal emulator and version are you using (if applicable)? Windows Terminal `1.24.11911.0` with PowerShell `7.6.4` (`Core`, x64). ### Codex doctor report Not included. The reproduction uses only the standalone `codex execpolicy check` command with isolated rule files. It does not depend on installation discovery, authentication, terminal state, MCP servers, networking, or the Codex state database. ### What issue are you seeing? When a Windows user creates a durable allow rule for a bare PowerShell command, Codex cannot bind that rule to the launcher path the user intended to trust. For example, a global npm installation of Agent Playwright CLI is normally invoked as: ```powershell playwright-cli --version ``` PowerShell resolves that command to: ```text C:\\Users\\\\AppData\\Roaming\\npm\\playwright-cli.ps1 ``` The two available rule forms each lose one important property: 1. An absolute-path `prefix_rule` restricts authority to the intended launcher, but it does not match the normal bare invocation. 2. A bare-name `prefix_rule(pattern = [\"playwright-cli\"])` matches the normal invocation, but it grants authority to whichever command PowerShell later resolves under that name. The current `host_executable()` support does not bridge this gap. It supports the opposite direction: when the parsed command already contains an absolute executable path, a basename rule can match that path subject to `host_executable()` metadata. This leaves users choosing between less ergonomic, shell-specific absolute-path invocations and durable authority that is sensitive to later PATH or command-resolution changes. This is not a claim that the current bare-rule behavior violates its documented contract; it is a gap in safely expressing the user's intended trust boundary. ### What steps can reproduce the bug? 1. Install a command that PowerShell resolves by name. Agent Playwright CLI is one concrete example: ```powershell npm install -g @playwright/cli@0.1.17 Get-Command playwright-cli | Format-List Name,Path,CommandType ``` Observed resolution: ```text Name : playwright-cli.ps1 Path : C:\\Users\\\\AppData\\Roaming\\npm\\playwright-cli.ps1 CommandType : ExternalScript ``` 2. Create `absolute.rules`: ```starlark prefix_rule( pattern = [\"C:\\\\Users\\\\\\\\AppData\\\\Roaming\\\\npm\\\\playwright-cli.ps1\"], decision = \"allow\", ) ``` 3. Check the normal bare invocation: ```powershell codex execpolicy check --pretty --rules .\\absolute.rules -- playwright-cli --version ``` Observed: ```json { \"matchedRules\": [] } ``` 4. Check the absolute invocation: ```powershell codex execpolicy check --pretty --rules .\\absolute.rules -- \"C:\\Users\\\\AppData\\Roaming\\npm\\playwright-cli.ps1\" --version ``` Observed: ```json { \"matchedRules\": [ { \"prefixRuleMatch\": { \"matchedPrefix\": [ \"C:\\\\Users\\\\\\\\AppData\\\\Roaming\\\\npm\\\\playwright-cli.ps1\" ], \"decision\": \"allow\" } } ], \"decision\": \"allow\" } ``` 5. Create `bare.rules` with a bare-name rule: ```starlark prefix_rule( pattern = [\"playwright-cli\"], decision = \"allow\", ) ``` 6. Check the normal invocation again: ```powershell codex execpolicy check --pretty --rules .\\bare.rules -- playwright-cli --version ``` Observed: ```json { \"matchedRules\": [ { \"prefixRuleMatch\": { \"matchedPrefix\": [ \"playwright-cli\" ], \"decision\": \"allow\" } } ], \"decision\": \"allow\" } ``` No thread ID is applicable because the reproduction uses `codex execpolicy check`. #### Evidence boundary The checks above demonstrate only the rule-language mismatch; `codex execpolicy check` does not execute the command. In `rust-v0.146.0`, preflight can lower a PowerShell `-Command` body for matching, but the shell runtime later executes the original wrapper argv; `resolvedProgram` is matcher metadata, not an executor-bound target. This source-level separation motivates the execution-binding concern, but the checker output alone does not demonstrate a sandbox escape. ### What is the expected behavior? Codex should provide a path-bound way to authorize a bare external command without granting durable authority to any future command that happens to resolve under the same name. The policy check and execution must bind to the same target. Codex should not verify one resolved path and then hand the original bare name back to PowerShell for a second, potentially different resolution. If Codex cannot safely preserve that binding for a particular PowerShell command shape, it should conservatively keep the command sandboxed or request approval. ### Additional information #### Suggested design direction One possible extension would let `host_executable()` opt into resolving a bare command through an explicit path mapping: ```starlark host_executable( name = \"playwright-cli\", paths = [ \"C:\\\\Users\\\\\\\\AppData\\\\Roaming\\\\npm\\\\playwright-cli.ps1\", ], resolve_bare = True, ) prefix_rule( pattern = [\"playwright-cli\"], decision = \"allow\", ) ``` The syntax is only illustrative. In 0.146.0, `host_executable()` is reverse-match metadata, `paths` is an allowlist rather than target-selection order, and Windows executable-name normalization does not include `.ps1`. A separate typed binding primitive may therefore be clearer than overloading `host_executable()`. The important semantics are: - Construct one immutable launch plan before `allow`: the logical command, exact configured target, launcher kind, required interpreter, and lossless arguments. - Carry that plan through policy display, approval/cache identity, sandbox transforms, retries, and spawn. Never re-resolve it; if it cannot be honored, require fresh evaluation and approval. - Collect every authored explicit match across the logical command, bound path, and required interpreter, then apply `forbidden > prompt > allow`. Apply the unmatched-command fallback once only if that combined explicit-match set is empty. - Initially require exactly one eligible target. Future multiple-candidate priority must be explicit policy data, not PATH/PATHEXT, discovery order, existence, or unordered-list order. - After binding, shell resolution mechanisms must not replace the launcher or interpreter. Missing, non-file, unsupported, ambiguous, or mismatched plans must fail closed. For a provably single external invocation with lossless arguments, Codex could construct a typed launcher plan. `.exe`/`.com` can use the configured absolute application path. `.cmd`/`.bat` must bind an exact trusted `cmd.exe` and script, disable AutoRun with `/d`, and use injection-safe `/s /c` encoding. `.ps1` must bind the exact script and PowerShell path, flavor, and flags without another lookup. Do not rebuild arbitrary source from lossy argv-like lowering; unsupported forms must remain sandboxed or approval-gated. #### Suggested regression coverage - One-to-one bindings for `.exe`, `.com`, `.cmd`, `.bat`, and `.ps1`, including the exact interpreter for script launchers. - Changes to PATH, PATHEXT, `ComSpec`, file associations, aliases, functions, cmdlets, module auto-loading, or profiles must not replace the bound target or interpreter. - An unlisted absolute path must not inherit `allow`, and a restrictive authored rule on the logical name, bound path, or interpreter must win over an `allow` on another representation. - Approval-cache reuse and sandbox or credential retries must retain the complete plan; any re-binding must trigger fresh policy evaluation and approval. - Empty arguments, embedded quotes, metacharacters, expressions, splatting, redirection, pipelines, and `--%` must either retain their original semantics or fail closed before a path-bound `allow`. This proposal binds configured launcher and interpreter paths, not file objects or content digests. In-place modification, rename or replacement, hard-link substitution, and symlink, junction, reparse-point, or ancestor-path retargeting remain TOCTOU unless separate file-identity controls are added. Those are the same class of limitations as existing absolute-path rules. The narrower invariant here is that Codex performs no second name-based lookup of the launcher or required interpreter after policy selects the plan. #### Related work - #13175 (closed as a duplicate of #11298), #13502, and #15294 cover broader shell-wrapper, Windows rule-matching, and native-CLI ergonomics problems. - #24201 covers `execpolicy check` not mirroring runtime PowerShell-wrapper normalization; this reproduction intentionally uses raw inner tokens and concerns bare-name authority instead. - #37079 covers the complementary case where a basename `forbidden` rule can be bypassed through an unregistered absolute lookalike path. This report concerns binding a bare-name `allow` to one configured launcher and carrying that same target through execution. - Merged PRs #12964 and #13065 added `host_executable()` matching for commands that already contain absolute paths, and merged PR #20336 made top-level PowerShell wrappers transparent to inner-command matching. - Closed, unmerged PR #29845 carried an optional explicit application path through Windows launchers without changing resolution policy. Closed, unmerged PR #30036 built on it to resolve native executables once and reuse the path, while intentionally rejecting `.cmd`/`.bat`. - Open PRs #30628 and #31019 recognize that parsed inner command names do not by themselves bind runtime PATH, module, profile, or wrapper resolution. - Open PR #30631 applies a resolve-once, carry-to-policy/display/cache/spawn invariant to model-selected shell executables, but not to general parsed inner commands or script launchers. - Open PR #30990 preserves restrictive decisions across Windows path aliases; the same fail-closed principle applies when combining logical-name, bound-path, and interpreter matches. This report is about providing a supported path-bound mechanism rather than restoring unrestricted PATH-sensitive durable authority. I did not find an existing public issue or PR that provides a policy-configured binding from a general parsed inner bare PowerShell command to one exact Windows launcher plan across native and script launcher kinds.", "url": "https://github.com/openai/codex/issues/36179", "createdAt": "2026-07-30T16:15:42Z", "updatedAt": "2026-08-13T07:10:40Z", "timestamp": "2026-08-13T07:10:40Z", "metrics": { "reactions": 0, "comments": 0 }, "labels": [ "enhancement", "windows-os", "sandbox", "CLI" ], "author": "starriet9", "state": "open", "assignees": [] }, { "id": "github:openai/codex:issue:36211", "source": "github", "group": "coding-agent-infrastructure", "project": "openai/codex", "kind": "issue", "title": "close_agent is missing from the VS Code multi-agent tool schema", "text": "### What version of the IDE extension are you using? 26.721.41059 ### What subscription do you have? ChatGPT Plus ### Which IDE are you using? Visual Studio Code 1.131.0 using Remote - WSL ### What platform is your computer? Microsoft Windows NT 10.0.19045.0 x64 ### What issue are you seeing? In new Codex chats opened through the VS Code extension, `close_agent` is missing from the callable collaboration-tool schema even though `multi_agent` is enabled. The affected sessions expose: - `spawn_agent` - `followup_task` - `send_message` - `interrupt_agent` - `list_agents` - `wait_agent` They do not expose `close_agent`. This is partial tool exposure: multi-agent support is available, but the operation needed to close a completed subagent is missing. `interrupt_agent` is not a replacement because it only interrupts the agent's current turn and explicitly leaves the agent available. The issue persists after updating the extension, completely restarting VS Code, and creating multiple brand-new chats. ### What steps can reproduce the bug? 1. Enable multi-agent support in `~/.codex/config.toml`: [features] multi_agent = true 2. Restart VS Code and open a Git repository through Remote - WSL. 3. Open a new Codex chat and send this exact request: Use a subagent to list the repository's top-level files. Wait for the subagent to finish, close it using close_agent, and report the lifecycle operations you performed. 4. Observe that the session can access `spawn_agent` and `wait_agent`, but cannot perform the requested cleanup because `close_agent` is absent from its callable tool schema. The available cleanup-adjacent operation is `interrupt_agent`, which interrupts the current turn but leaves the agent available. ### What is the expected behavior? With stable `multi_agent` enabled, every new VS Code Codex chat should receive the complete documented collaboration lifecycle, including a callable `close_agent` operation. A workflow should be able to: 1. spawn a child agent; 2. wait for its result; 3. explicitly close the child; 4. verify that the child reached a terminal state and its slot was reclaimed. If `close_agent` has intentionally been replaced, the extension should expose and document an equivalent finalization operation. `interrupt_agent` should not be treated as equivalent to lifecycle closure. ### Additional information The Codex runtime bundled with the affected extension reports: ```text codex-cli 0.146.0-alpha.3.1 ``` Relevant configuration: ```toml [features] multi_agent = true ``` The VS Code workspace is opened through Remote - WSL with Ubuntu 24.04.4 LTS. The Windows host platform is recorded in the dedicated platform field above.", "url": "https://github.com/openai/codex/issues/36211", "createdAt": "2026-07-30T19:43:15Z", "updatedAt": "2026-08-12T21:02:03Z", "timestamp": "2026-08-12T21:02:03Z", "metrics": { "reactions": 0, "comments": 4 }, "labels": [ "bug", "windows-os", "extension", "subagent" ], "author": "gcalpay", "state": "open", "assignees": [] }, { "id": "github:openai/codex:issue:36229", "source": "github", "group": "coding-agent-infrastructure", "project": "openai/codex", "kind": "issue", "title": "GPT‑5.6 regression: stronger planning, weaker execution and instruction adherence", "text": "### What version of Codex CLI is running? codex-cli 0.146.0 ### What subscription do you have? max ### Which model were you using? gpt 5.6 sol high ### What platform is your computer? Microsoft Windows NT 10.0.26200.0 x64 ### What terminal emulator and version are you using (if applicable)? Windows Terminal Powershell 7.6.4, Core ### Codex doctor report ```json ``` ### What issue are you seeing? > Compared with GPT‑5.5, GPT‑5.6 appears stronger at planning, architectural assessment, and identifying risks, but weaker at straightforward execution and instruction adherence. It more frequently re-plans, expands scope, or follows inferred/persistent goals > instead of carrying out the latest explicit instruction. GPT‑5.5 felt more direct and reliably completed the requested work, while GPT‑5.6 often produces a better analysis but a worse operational result. This pattern has repeated across several unrelated > projects. ### What steps can reproduce the bug? Uploaded thread: 019fb46d-7bed-7352-aac2-08e399888a05 ### What is the expected behavior? _No response_ ### Additional information _No response_", "url": "https://github.com/openai/codex/issues/36229", "createdAt": "2026-07-30T21:50:07Z", "updatedAt": "2026-08-13T06:49:53Z", "timestamp": "2026-08-13T06:49:53Z", "metrics": { "reactions": 0, "comments": 5 }, "labels": [ "bug", "model-behavior", "windows-os", "CLI" ], "author": "hanktos", "state": "open", "assignees": [] }, { "id": "github:openai/codex:issue:36232", "source": "github", "group": "coding-agent-infrastructure", "project": "openai/codex", "kind": "issue", "title": "Current Windows Desktop still fails remote compaction for image-heavy long-running tasks (reconnect 5/5)", "text": "### Summary A long-running, image-heavy Codex Desktop task repeatedly enters `Reconnecting 1/5` through `Reconnecting 5/5` during automatic context compaction and then reports: ```text Error running remote compact task: stream disconnected before completion: error sending request for url (https://chatgpt.com/backend-api/codex/responses) ``` This is still reproducible on the current Windows Desktop build. The affected task can remain slow or unresponsive for minutes, while ordinary tasks in the same app and Codex CLI on the same machine respond normally. ### Environment - Product: Codex Desktop - App version: `26.721.11231.0` - Platform: Windows 11 x64 - Observed: July 2026 - Task pattern: long-running task with repeated image/browser inputs and many automatic compactions ### Reproduction pattern 1. Keep one Codex Desktop task active across many turns. 2. Add screenshots or browser/image-tool results over time. 3. Allow automatic compaction to occur repeatedly. 4. Send an otherwise routine text request when the task is near another compaction. 5. Observe `Context automatically compacting`, repeated reconnect attempts, and sometimes the remote compact error above. ### Sanitized diagnostic evidence A read-only inspection of the affected task found: - The append-only rollout had grown past 1 GB after many compactions. - The latest active replacement history was approximately 51 MB uncompressed (approximately 38 MB compressed). - The active history retained dozens of historical inline images; image data accounted for nearly all payload bytes. - The same remote-compaction stream failure recurred on multiple days. - A compaction retry can eventually succeed, but historical image payloads remain in replacement history, so the oversized request shape and failure risk return. - HTTP reachability and the Responses WebSocket handshake were healthy. - Control tasks in the same Desktop process had much smaller request payloads and responded normally. - Lowering model/reasoning effort improved an ordinary response but did not remove the oversized compaction payload or prevent recurrence. No private rollout, screenshots, local paths, task IDs, project details, or user content are attached. ### Actual behavior - Automatic compaction sends a very large image-heavy replacement history. - The response stream disconnects before completion. - Desktop retries up to five times and may remain stuck or slow for minutes. - Even after a successful retry, retained historical image bytes make the problem recur. ### Expected behavior - Compaction should summarize, externalize, or deduplicate historical image bytes rather than carry full inline payloads indefinitely. - Request and retained-image size should remain bounded across repeated compactions. - If remote compaction fails, Desktop should recover with a supported fallback instead of an extended reconnect loop. - The UI should identify payload/compaction pressure distinctly from a general network failure. ### Related reports - #34863 — repeated inline PNG data URLs make compacted records and app-server memory grow - #24550 — large inline images in compacted `replacement_history` trigger Responses WebSocket fallback - #30958 — exact `stream disconnected before completion` endpoint error on Windows Desktop - #31375 — context compression disconnects repeatedly in the Codex App - #32545 — Windows Desktop remote-compaction disconnect regression This report is intended as a current Windows Desktop corroboration tying the exact remote-compaction error and reconnect loop to measured image-heavy replacement-history payload pressure.", "url": "https://github.com/openai/codex/issues/36232", "createdAt": "2026-07-30T22:06:56Z", "updatedAt": "2026-08-13T12:54:37Z", "timestamp": "2026-08-13T12:54:37Z", "metrics": { "reactions": 0, "comments": 3 }, "labels": [ "bug", "windows-os", "context", "app", "connectivity" ], "author": "charlesonogwu", "state": "open", "assignees": [] }, { "id": "github:openai/codex:issue:36338", "source": "github", "group": "coding-agent-infrastructure", "project": "openai/codex", "kind": "issue", "title": "Codex TUI freezes after Zellij detach/reattach; suspending before detach avoids it", "text": "When Codex is running in the foreground of a Zellij pane, detaching and reattaching the Zellij session reliably leaves the Codex TUI frozen. The Codex process remains alive, but the pane no longer displays updates or visible keyboard input. Resizing or zooming the pane does not cause Codex to redraw. Suspending Codex with Ctrl+Z before detaching, then running `fg` after reattaching, avoids the problem. ## Environment - OS: Arch Linux - Desktop/compositor: Hyprland / Wayland - Codex CLI: 0.146.0 - Also reproduced on Codex CLI: 0.144.5 - Zellij: 0.44.3 - Kitty: 0.47.4 - Kernel: Linux 7.1.3-arch2-1 - TERM: screen-256color - COLORTERM: truecolor - ZELLIJ: 0 - Zellij session contains vertically split panes ## Steps to reproduce 1. Open Kitty under Hyprland. 2. Start or attach to a Zellij session. 3. Start Codex in a Zellij pane. 4. Verify that Codex accepts input and updates normally. 5. Leave Codex running in the foreground. 6. Detach from Zellij normally. 7. Reattach to the same Zellij session. 8. Try typing into Codex or wait for an update. ## Expected behavior Codex should continue accepting input and redraw normally after the Zellij session is reattached. ## Actual behavior The Codex pane remains visually frozen. New input and updates are not shown. If the pane is zoomed from approximately half the terminal width to full width, the old Codex contents remain on the left at their previous width, while the newly exposed right side is blank. This indicates that Codex is not processing the resize or redraw after reattachment. ## Reproducibility Reliable on this machine when detaching and reattaching Zellij. Changing Zellij tabs without detaching does not reproduce the problem. A second workstation with a similar software stack does not reproduce it. That workstation has a substantially larger display, so terminal dimensions or redraw load might influence whether the issue triggers. ## Attempted troubleshooting The following did not recover or prevent the frozen TUI: - Upgrading Codex from 0.144.5 to 0.146.0 - Resetting the Kitty terminal - Sending SIGWINCH to Codex - Setting `tui.alternate_screen = \"always\"` - Switching Zellij tabs - Zooming/resizing the Zellij pane The Codex process was still alive and in the foreground when inspected. ## Working workaround Before detaching: 1. Press Ctrl+Z to suspend Codex. 2. Detach from Zellij. After reattaching: 1. Run `fg`. Codex then resumes, redraws, and accepts input normally. This suggests that the Codex TUI event/render loop does not survive Zellij's detach/reattach terminal lifecycle while Codex owns the foreground terminal, whereas SIGCONT/foreground restor", "url": "https://github.com/openai/codex/issues/36338", "createdAt": "2026-07-31T14:39:12Z", "updatedAt": "2026-08-13T08:34:01Z", "timestamp": "2026-08-13T08:34:01Z", "metrics": { "reactions": 5, "comments": 4 }, "labels": [ "bug", "TUI", "CLI" ], "author": "fakegiraffe", "state": "open", "assignees": [] }, { "id": "github:openai/codex:issue:36358", "source": "github", "group": "coding-agent-infrastructure", "project": "openai/codex", "kind": "issue", "title": "Bug: Answers Are Internally Truncated Unpredictably", "text": "(not duplicate of https://github.com/openai/codex/issues/36112) ### What version of Codex CLI is running? codex-cli 0.146.0 ### What subscription do you have? Plus ### Which model were you using? gpt-5.6-luna low ### What platform is your computer? Microsoft Windows NT 10.0.26200.0 x64 ### What terminal emulator and version are you using (if applicable)? WSL/PS7 ### Codex doctor report ```json { \"schemaVersion\": 1, \"generatedAt\": \"1785514400s since unix epoch\", \"overallStatus\": \"ok\", \"codexVersion\": \"0.146.0\", \"checks\": { \"app_server.status\": { \"id\": \"app_server.status\", \"category\": \"app-server\", \"status\": \"ok\", \"summary\": \"background server is not running\", \"details\": { \"control socket\": \"/home/devuser/.codex/app-server-control/app-server-control.sock\", \"daemon state dir\": \"/home/devuser/.codex/app-server-daemon\", \"mode\": \"ephemeral\", \"pid file\": \"/home/devuser/.codex/app-server-daemon/app-server.pid (missing)\", \"settings\": \"/home/devuser/.codex/app-server-daemon/settings.json (missing)\", \"status\": \"not running\", \"update-loop pid file\": \"/home/devuser/.codex/app-server-daemon/app-server-updater.pid (missing)\" }, \"remediation\": null, \"durationMs\": 0 }, \"auth.credentials\": { \"id\": \"auth.credentials\", \"category\": \"auth\", \"status\": \"ok\", \"summary\": \"auth is configured\", \"details\": { \"auth file\": \"/home/devuser/.codex/auth.json\", \"auth storage mode\": \"File\", \"stored API key\": \"false\", \"stored ChatGPT tokens\": \"true\", \"stored agent identity\": \"false\", \"stored auth mode\": \"chatgpt\" }, \"remediation\": null, \"durationMs\": 0 }, \"config.load\": { \"id\": \"config.load\", \"category\": \"config\", \"status\": \"ok\", \"summary\": \"config loaded\", \"details\": { \"CODEX_HOME\": \"/home/devuser/.codex\", \"config.toml\": \"/home/devuser/.codex/config.toml\", \"config.toml parse\": \"ok\", \"cwd\": \"/mnt/c/Users/Naj/git/daemon\", \"enabled feature flags\": \"shell_tool, unified_exec, shell_snapshot, code_mode_host, terminal_resize_reflow, sqlite, hooks, enable_request_compression, multi_agent, apps, tool_search_always_defer_mcp_tools, tool_suggest, plugins, in_app_browser, in_app_updates, browser_use, browser_use_full_cdp_access, browser_use_external, computer_use, remote_plugin, plugin_sharing, image_generation, resize_all_images, item_ids, skill_mcp_dependency_install, skill_search, mentions_v2, steer, guardian_approval, goals, collaboration_modes, tool_call_mcp_elicitation, auth_elicitation, personality, fast_mode, tui_app_server, remote_compaction_v2, workspace_dependencies\", \"feature flag overrides\": \"none\", \"feature flags enabled\": \"38\", \"log dir\": \"/home/devuser/.codex/log\", \"mcp servers\": \"0\", \"model\": \"gpt-5.6-luna\", \"model provider\": \"openai\", \"sqlite home\": \"/home/devuser/.codex\" }, \"remediation\": null, \"durationMs\": 0 }, \"git.environment\": { \"id\": \"git.environment\", \"category\": \"git\", \"status\": \"ok\", \"summary\": \"git version 2.55.0\", \"details\": { \".git entry\": \"directory\", \"PATH git #1\": \"/usr/sbin/git\", \"PATH git #2\": \"/usr/bin/git\", \"PATH git #3\": \"/sbin/git\", \"PATH git #4\": \"/bin/git\", \"PATH git entries\": \"4\", \"git branch\": \"main\", \"git build options\": \"git version 2.55.0; cpu: x86_64; built from commit: e9019fcafe0040228b8631c30f97ae1adb61bcdc; sizeof-long: 8; sizeof-size_t: 8; shell-path: /bin/sh; rust: enabled; feature: fsmonitor--daemon; gettext: enabled; libcurl: 8.21.0; OpenSSL: OpenSSL 3.6.3 9 Jun 2026; zlib-ng: 2.3.3; SHA-1: SHA1_DC; SHA-256: SHA256_BLK; default-ref-format: files; default-hash: sha1\", \"git exec path\": \"/usr/lib/git-core\", \"git version\": \"git version 2.55.0\", \"repo detected\": \"true\", \"repo root\": \"/mnt/c/Users/Naj/git/daemon\", \"selected git\": \"/usr/sbin/git\" }, \"remediation\": null, \"durationMs\": 100 }, \"installation\": { \"id\": \"installation\", \"category\": \"install\", \"status\": \"ok\", \"summary\": \"installation looks consistent\", \"details\": { \"PATH codex #1\": \"/usr/sbin/codex\", \"PATH codex #2\": \"/usr/bin/codex\", \"PATH codex #3\": \"/sbin/codex\", \"PATH codex #4\": \"/bin/codex\", \"PATH codex entries\": \"4\", \"current executable\": \"/usr/lib/node_modules/@openai/codex/node_modules/@openai/codex-linux-x64/vendor/x86_64-unknown-linux-musl/bin/codex\", \"install context\": \"npm (package /usr/lib/node_modules/@openai/codex/node_modules/@openai/codex-linux-x64/vendor/x86_64-unknown-linux-musl, bin /usr/lib/node_modules/@openai/codex/node_modules/@openai/codex-linux-x64/vendor/x86_64-unknown-linux-musl/bin, resources /usr/lib/node_modules/@openai/codex/node_modules/@openai/codex-linux-x64/vendor/x86_64-unknown-linux-musl/codex-resources, path /usr/lib/node_modules/@openai/codex/node_modules/@openai/codex-linux-x64/vendor/x86_64-unknown-linux-musl/codex-path)\", \"managed by bun\": \"false\", \"managed by npm\": \"true\", \"managed by pnpm\": \"false\", \"managed package root\": \"/usr/lib/node_modules/@openai/codex\", \"npm update target\": \"/usr/lib/node_modules/@openai/codex\" }, \"remediation\": null, \"durationMs\": 124 }, \"mcp.config\": { \"id\": \"mcp.config\", \"category\": \"mcp\", \"status\": \"ok\", \"summary\": \"no MCP servers configured\", \"details\": {}, \"remediation\": null, \"durationMs\": 0 }, \"network.env\": { \"id\": \"network.env\", \"category\": \"network\", \"status\": \"ok\", \"summary\": \"network-related environment looks readable\", \"details\": { \"proxy env vars\": \"none\" }, \"remediation\": null, \"durationMs\": 0 }, \"network.provider_reachability\": { \"id\": \"network.provider_reachability\", \"category\": \"reachability\", \"status\": \"ok\", \"summary\": \"active provider endpoints are reachable over HTTP\", \"details\": { \"ChatGPT base URL\": \"https://chatgpt.com/backend-api/ reachable (HTTP 404)\", \"reachability mode\": \"ChatGPT auth\" }, \"remediation\": null, \"durationMs\": 191 }, \"network.websocket_reachability\": { \"id\": \"network.websocket_reachability\", \"category\": \"websocket\", \"status\": \"ok\", \"summary\": \"Responses WebSocket handshake succeeded\", \"details\": { \"DNS\": \"2 IPv4, 2 IPv6, first IPv4\", \"auth mode\": \"chatgpt\", \"connect timeout\": \"15000 ms\", \"endpoint\": \"wss://chatgpt.com/backend-api/\", \"handshake result\": \"HTTP 101 Switching Protocols\", \"model provider\": \"openai\", \"models etag present\": \"true\", \"provider name\": \"OpenAI\", \"proxy env vars\": \"none\", \"reasoning header\": \"false\", \"server model present\": \"false\", \"supports websockets\": \"true\", \"wire API\": \"responses\" }, \"remediation\": null, \"durationMs\": 634 }, \"runtime.provenance\": { \"id\": \"runtime.provenance\", \"category\": \"runtime\", \"status\": \"ok\", \"summary\": \"running npm on linux-x86_64\", \"details\": { \"commit\": \"unknown\", \"current executable\": \"/usr/lib/node_modules/@openai/codex/node_modules/@openai/codex-linux-x64/vendor/x86_64-unknown-linux-musl/bin/codex\", \"install method\": \"npm (package /usr/lib/node_modules/@openai/codex/node_modules/@openai/codex-linux-x64/vendor/x86_64-unknown-linux-musl, bin /usr/lib/node_modules/@openai/codex/node_modules/@openai/codex-linux-x64/vendor/x86_64-unknown-linux-musl/bin, resources /usr/lib/node_modules/@openai/codex/node_modules/@openai/codex-linux-x64/vendor/x86_64-unknown-linux-musl/codex-resources, path /usr/lib/node_modules/@openai/codex/node_modules/@openai/codex-linux-x64/vendor/x86_64-unknown-linux-musl/codex-path)\", \"platform\": \"linux-x86_64\", \"version\": \"0.146.0\" }, \"remediation\": null, \"durationMs\": 0 }, \"runtime.search\": { \"id\": \"runtime.search\", \"category\": \"search\", \"status\": \"ok\", \"summary\": \"search is OK (bundled)\", \"details\": { \"search command\": \"/usr/lib/node_modules/@openai/codex/node_modules/@openai/codex-linux-x64/vendor/x86_64-unknown-linux-musl/codex-path/rg\", \"search command readiness\": \"file exists\", \"search provider\": \"bundled\" }, \"remediation\": null, \"durationMs\": 0 }, \"sandbox.helpers\": { \"id\": \"sandbox.helpers\", \"category\": \"sandbox\", \"status\": \"ok\", \"summary\": \"sandbox configuration is readable\", \"details\": { \"approval policy\": \"OnRequest\", \"codex-linux-sandbox helper\": \"/home/devuser/.codex/tmp/arg0/codex-arg0rbNFJi/codex-linux-sandbox\", \"execve wrapper helper\": \"/home/devuser/.codex/tmp/arg0/codex-arg0rbNFJi/codex-execve-wrapper\", \"filesystem sandbox\": \"restricted\", \"network sandbox\": \"restricted\" }, \"remediation\": null, \"durationMs\": 0 }, \"state.paths\": { \"id\": \"state.paths\", \"category\": \"state\", \"status\": \"ok\", \"summary\": \"state paths and databases are inspectable\", \"details\": { \"CODEX_HOME\": \"/home/devuser/.codex (dir)\", \"active rollout files\": \"4 files, 7078293 total bytes, 1769573 average bytes\", \"archived rollout files\": \"0 files, 0 total bytes, 0 average bytes\", \"goals DB\": \"/home/devuser/.codex/goals_1.sqlite (file)\", \"goals DB integrity\": \"ok\", \"log DB\": \"/home/devuser/.codex/logs_2.sqlite (file)\", \"log DB integrity\": \"ok\", \"log dir\": \"/home/devuser/.codex/log (missing)\", \"memories DB\": \"/home/devuser/.codex/memories_1.sqlite (file)\", \"memories DB integrity\": \"ok\", \"sqlite home\": \"/home/devuser/.codex (dir)\", \"state DB\": \"/home/devuser/.codex/state_5.sqlite (file)\", \"state DB integrity\": \"ok\", \"thread history DB\": \"/home/devuser/.codex/thread_history_1.sqlite (missing)\", \"thread history DB integrity\": \"skipped (missing)\" }, \"remediation\": null, \"durationMs\": 90 }, \"state.rollout_db_parity\": { \"id\": \"state.rollout_db_parity\", \"category\": \"threads\", \"status\": \"ok\", \"summary\": \"rollout files and state DB thread inventory agree\", \"details\": { \"default model provider\": \"openai\", \"rollout DB active files\": \"4\", \"rollout DB active rows\": \"4\", \"rollout DB archive mismatches\": \"0\", \"rollout DB archived files\": \"0\", \"rollout DB archived rows\": \"0\", \"rollout DB duplicate DB paths\": \"0\", \"rollout DB duplicate rollout thread ids\": \"0\", \"rollout DB malformed file names\": \"0\", \"rollout DB missing active rows\": \"0\", \"rollout DB missing archived rows\": \"0\", \"rollout DB model providers\": \"openai=4\", \"rollout DB rows\": \"4\", \"rollout DB scan cap reached\": \"false\", \"rollout DB scan errors\": \"0\", \"rollout DB sources\": \"cli=4\", \"rollout DB stale rows\": \"0\" }, \"remediation\": null, \"durationMs\": 71 }, \"system.environment\": { \"id\": \"system.environment\", \"category\": \"system\", \"status\": \"ok\", \"summary\": \"OS language C\", \"details\": { \"EDITOR\": \"not set\", \"LANG\": \"C.UTF-8\", \"VISUAL\": \"not set\", \"os\": \"Arch Linux [64-bit]\", \"os language\": \"C\", \"os type\": \"Arch Linux\", \"os version\": \"Unknown\" }, \"remediation\": null, \"durationMs\": 19 }, \"terminal.env\": { \"id\": \"terminal.env\", \"category\": \"terminal\", \"status\": \"ok\", \"summary\": \"terminal metadata was detected\", \"details\": { \"DISPLAY\": \"present\", \"WAYLAND_DISPLAY\": \"present\", \"WSL_DISTRO_NAME\": \"present\", \"WSL_INTEROP\": \"present\", \"WT_SESSION\": \"present\", \"color output\": \"enabled\", \"effective locale\": \"C.UTF-8\", \"stderr is terminal\": \"true\", \"stdin is terminal\": \"true\", \"stdout is terminal\": \"true\", \"terminal\": \"Windows Terminal\", \"terminal size\": \"133x35\" }, \"remediation\": null, \"durationMs\": 0 }, \"terminal.title\": { \"id\": \"terminal.title\", \"category\": \"title\", \"status\": \"ok\", \"summary\": \"terminal title default\", \"details\": { \"terminal title activity\": \"true\", \"terminal title items\": \"activity, project-name\", \"terminal title project source\": \"git repo root\", \"terminal title project value\": \"daemon\", \"terminal title source\": \"default\" }, \"remediation\": null, \"durationMs\": 1 }, \"updates.status\": { \"id\": \"updates.status\", \"category\": \"updates\", \"status\": \"ok\", \"summary\": \"update configuration is locally consistent\", \"details\": { \"cached latest version\": \"0.146.0\", \"check for update on startup\": \"true\", \"last checked at\": \"2026-07-31T14:22:49.453256538Z\", \"latest version\": \"0.146.0\", \"latest version status\": \"current version is not older\", \"npm update target\": \"/usr/lib/node_modules/@openai/codex\", \"update action\": \"npm install -g @openai/codex\", \"version cache\": \"/home/devuser/.codex/version.json\" }, \"remediation\": null, \"durationMs\": 527 } } } ``` ### What issue are you seeing? Some answers are getting truncated. When they are first displayed, the full answer is visible. After i reply, then if i scroll up, the full answer is no longer visible. original five-item answer: \"Image\" my quoting of one item from the list -- the item now missing from the list. \"Image\" scroll up and see only four visible items. \"Image\" agent knows it gave me five items. The title of the missing item matches what i quoted in my reply. \"Image\" \"Image\" scroll up and see the missing item magically restored: \"Image\" ### What steps can reproduce the bug? 1. submit a query which outputs a list. 2. copy one item in the list by highlighting with mouse, and then CTRL-SHIFT-c 3. begin to type your reply, and paste in the copied text 4. scroll up. The list is truncated. The copied item, or some other item, is missing. 5. ask agent to repeat full text of missing item 6. the missing item now reappears in the previous answer ### What is the expected behavior? nothing in the history should disappear ### Additional information this is a blocker Another example, showing where the title of one entry, which was originally visible when first generated, is now missing. \"Image\"", "url": "https://github.com/openai/codex/issues/36358", "createdAt": "2026-07-31T16:25:18Z", "updatedAt": "2026-08-13T05:27:47Z", "timestamp": "2026-08-13T05:27:47Z", "metrics": { "reactions": 0, "comments": 6 }, "labels": [ "bug", "windows-os", "TUI", "CLI" ], "author": "johnaweiss", "state": "open", "assignees": [] }, { "id": "github:openai/codex:issue:36376", "source": "github", "group": "coding-agent-infrastructure", "project": "openai/codex", "kind": "issue", "title": "`0.147.0-alpha.4`: OpenAI parent still sends encrypted V2 task to non-OpenAI child after #35845", "text": "## Summary `0.147.0-alpha.4` still cannot deliver a MultiAgentV2 task from an OpenAI parent to a correctly selected non-OpenAI child, despite the plaintext collaboration support merged in #35845. The OpenAI parent returns a `collaboration.spawn_agent` call whose `message` is actual ciphertext and whose `encrypted_function_args` field is `null`. Codex therefore retains encrypted delivery. The non-OpenAI Responses child is spawned with the correct role, provider, model, and `multi_agent_version = \"v2\"`, but it receives an `agent_message` whose visible text stops after `Payload:` and whose assignment exists only as `encrypted_content`. The child reports that no task was received and does not execute it. #35845 adds plaintext delivery only when the function call explicitly carries `encrypted_function_args: []`. It does not cover this cross-provider topology, because an OpenAI parent emits an encrypted message rather than the empty plaintext marker. ## Environment - macOS: `Darwin 25.5.0 arm64 arm` - Codex App: `26.727.40816` - Bundled CLI: `0.146.0-alpha.9.2` - Latest alpha control: official `0.147.0-alpha.4` arm64 release asset - Parent: OpenAI / `gpt-5.6-sol` - Child: DeepSeek / `deepseek-v4-flash` - Child provider wire API: `responses` - Child model catalog: DeepSeek's current official Codex catalog metadata - Fork mode: `none` The same result was reproduced through Codex Desktop and through a clean persistent `codex exec` run. The payload-level details below are from the `0.147.0-alpha.4` run. ### Release provenance #35845 was merged as commit [`03edf16f0bce2c454fc9a8ddb382e9c23c114f7f`](https://github.com/openai/codex/commit/03edf16f0bce2c454fc9a8ddb382e9c23c114f7f). The official [`rust-v0.147.0-alpha.4`](https://github.com/openai/codex/releases/tag/rust-v0.147.0-alpha.4) tag contains that commit; GitHub's [commit-to-tag comparison](https://github.com/openai/codex/compare/03edf16f0bce2c454fc9a8ddb382e9c23c114f7f...rust-v0.147.0-alpha.4) reports the tag ahead of the merge commit with no commits behind it. The tested binary was the official `codex-aarch64-apple-darwin.tar.gz` release asset. Its downloaded SHA-256 was `faff3eb0d029647cc10aa8cad085018359fc622d99037e90988b58b606a68152`, matching the digest published by the GitHub release API. ## Relevant sanitized configuration ```toml [agents.deepseek_flash] description = \"DeepSeek V4 Flash subagent\" config_file = \"agents/deepseek-flash.toml\" [model_providers.deepseek] name = \"deepseek\" base_url = \"https://api.deepseek.com/\" wire_api = \"responses\" # Authentication omitted. ``` `agents/deepseek-flash.toml`: ```toml model = \"deepseek-v4-flash\" model_provider = \"deepseek\" model_catalog_json = \"~/.codex/models.json\" model_reasoning_effort = \"high\" ``` Relevant official catalog fields: ```json { \"slug\": \"deepseek-v4-flash\", \"multi_agent_version\": \"v2\", \"supports_reasoning_summaries\": true, \"minimal_client_version\": \"0.144.0\" } ``` DeepSeek's current Codex setup source: https://cdn.deepseek.com/api-docs/codex-deepseek-setup-en.sh ## Minimal reproduction 1. Configure the non-OpenAI child role above. 2. Start a persistent Codex session with an OpenAI `gpt-5.6-sol` parent. 3. Ask the parent to call `collaboration.spawn_agent` with: ```json { \"agent_type\": \"deepseek_flash\", \"fork_turns\": \"none\", \"task_name\": \"cross_provider_v2_canary\", \"message\": \"nonce CROSS_PROVIDER_V2; run pwd with the shell; return the nonce and real output\" } ``` 4. Wait for the child. A direct control on the bundled `0.146.0-alpha.9.2` succeeds: starting `deepseek-v4-flash` directly and asking it to run `pwd` produces the expected shell output. In the `0.147.0-alpha.4` child run, the same DeepSeek role also completes model turns and collaboration tool calls while reporting that no task arrived. Together these controls verify that the provider/model channel is operational independently of the task handoff. ## Actual behavior on `0.147.0-alpha.4` The runtime excerpts below retain the actual task name and thread IDs. Complete ciphertext and local paths are omitted. The child session metadata is correct: ```json { \"cli_version\": \"0.147.0-alpha.4\", \"model_provider\": \"deepseek\", \"agent_role\": \"deepseek_flash\", \"multi_agent_version\": \"v2\" } ``` The child turn context is also correct: ```json { \"model\": \"deepseek-v4-flash\", \"effort\": \"high\", \"multi_agent_version\": \"v2\" } ``` However, the parent function-call item contains: ```json { \"name\": \"spawn_agent\", \"namespace\": \"collaboration\", \"encrypted_function_args\": null, \"arguments\": { \"agent_type\": \"deepseek_flash\", \"fork_turns\": \"none\", \"task_name\": \"alpha147_ds_v2_canary\", \"message\": \"gAAAAA...\" } } ``` The child's first inter-agent item is: ```json { \"type\": \"agent_message\", \"author\": \"/root\", \"recipient\": \"/root/alpha147_ds_v2_canary\", \"content\": [ { \"type\": \"input_text\", \"text\": \"Message Type: NEW_TASK\\nTask name: /root/alpha147_ds_v2_canary\\nSender: /root\\nPayload:\\n\" }, { \"type\": \"encrypted_content\", \"encrypted_content\": \"gAAAAA...\" } ] } ``` The child sees no usable assignment, reports that no task payload arrived, and performs no requested `pwd` call. Depending on the continuation path, the parent can subsequently fail with: ```text stream disconnected before completion: Encrypted function output content could not be decrypted or decoded. ``` Thread IDs for internal correlation: - Parent: `019fb970-d912-7192-a013-73199c7716ca` - Child: `019fb970-f385-7ac1-aa54-991befb99055` No API keys, complete ciphertext, local paths, or unrelated prompt history are included here. ## Why #35845 does not cover this case #35845 correctly introduces plaintext collaboration delivery when a function call has `encrypted_function_args: []`. Its regression test creates that empty marker synthetically and verifies that the child receives a structured plaintext `NEW_TASK` message. In the real OpenAI-parent to non-OpenAI-child flow above, the parent response has `encrypted_function_args: null` and the `message` argument is already ciphertext. The new `DirectPlaintextMessage` branch is therefore not selected, and the custom child still receives opaque `encrypted_content`. This appears to leave no provider-aware path that can materialize the task for a non-OpenAI target child. ## Expected behavior When `agent_type` resolves to a non-OpenAI child provider, Codex should do one of the following: 1. Deliver the V2 task through the provider-neutral plaintext path introduced by #35845; or 2. Fail before spawning with a clear error explaining that encrypted cross-provider delegation is unsupported. Silently creating a correctly routed child with an unreadable task is the worst outcome because it appears successful at the spawn layer and can leave the parent waiting or retrying. ## Suggested regression test Add an end-to-end V2 test with: - an OpenAI parent function call; - a registered non-OpenAI Responses child role; - `fork_turns = \"none\"`; - a nonce-bearing task; - an assertion that the child receives the nonce as usable input text and executes a deterministic tool call. The test should exercise the real provider selection boundary, not only a synthetic `encrypted_function_args: []` event. If plaintext delivery cannot be supported, assert a fail-fast unsupported-provider error and that no empty-task child is created. ## Related issues and change - #34833 — cross-provider child cannot consume encrypted assignment on 0.145 - #36321 — DeepSeek child receives an empty task on 0.146 Desktop - #33267 — parent-side encrypted function-output decode failure - #26753 — encrypted collaboration tools require backend support - #35845 — plaintext collaboration tool messages; does not cover this encrypted OpenAI-parent path The distinct contribution of this report is a post-#35845 reproduction on `0.147.0-alpha.4`, plus the runtime evidence showing exactly why the new plaintext branch is not selected.", "url": "https://github.com/openai/codex/issues/36376", "createdAt": "2026-07-31T18:45:18Z", "updatedAt": "2026-08-13T14:21:18Z", "timestamp": "2026-08-13T14:21:18Z", "metrics": { "reactions": 5, "comments": 10 }, "labels": [ "bug", "custom-model", "subagent", "app-server" ], "author": "Qian9921", "state": "open", "assignees": [] }, { "id": "github:openai/codex:issue:36399", "source": "github", "group": "coding-agent-infrastructure", "project": "openai/codex", "kind": "issue", "title": "Android/Termux: sandbox reads /proc/sys/kernel/overflowuid before bwrap, fails with Permission denied", "text": "## Environment - Codex CLI: 0.146.0 (standalone) - Platform: Android 14 (aarch64), kernel 6.1.115 - Shell: Termux 0.119.0 - No proot, native Termux environment ## Problem Codex sandbox initialization fails on native Termux (no proot) because it reads `/proc/sys/kernel/overflowuid` **before** invoking bwrap. Android SELinux blocks this read, so the sandbox never initializes, regardless of whether bwrap is installed or not. ``` bwrap: Can't read /proc/sys/kernel/overflowuid: Permission denied ``` This error occurs on every shell execution. Codex then falls back to running commands outside the sandbox entirely. ## Steps to Reproduce 1. Install Codex CLI on native Termux (Android) 2. Run any command that triggers the sandbox 3. Observe `bwrap: Can't read /proc/sys/kernel/overflowuid: Permission denied` ## Why This Happens `/proc/sys/kernel/overflowuid` is a Linux kernel sysctl. On Android, SELinux restricts access to many sysctl files under `/proc/sys/`. This is by design and cannot be changed without root. ## Suggestion Codex should detect Android/Termux environments and gracefully degrade: - Detect via `/proc/version` containing `android` or presence of `/system/build.prop` - Skip the `overflowuid` check (or use the POSIX constant 65534 as fallback) - Optionally warn the user that sandbox is disabled, rather than failing silently ## Related - #11809 (native Termux auth/lock failures) - #30153 (bwrap fchdir error in proot Debian) - #36398 (apply_patch not working in rootless nethunter)", "url": "https://github.com/openai/codex/issues/36399", "createdAt": "2026-07-31T22:46:00Z", "updatedAt": "2026-08-13T17:10:00Z", "timestamp": "2026-08-13T17:10:00Z", "metrics": { "reactions": 0, "comments": 0 }, "labels": [ "bug", "sandbox", "CLI" ], "author": "maxwell-feng", "state": "closed", "assignees": [] }, { "id": "github:openai/codex:issue:36488", "source": "github", "group": "coding-agent-infrastructure", "project": "openai/codex", "kind": "issue", "title": "Pro weekly usage drained 26% for 75.25M mostly cached tokens immediately after Aug 1 global reset", "text": "### Subscription ChatGPT Pro ### Models used - `gpt-5.6-sol` - `gpt-5.5` ### Issue Immediately after the global Codex usage reset announced by Tibo on **August 1, 2026**, my weekly Pro allowance began draining much faster than it did before the reset. On August 1, a total of **75,250,381 tokens** consumed approximately **26% of the weekly Pro allowance**, leaving 74% remaining. Comparable usage was behaving normally as recently as July 30-31, before this reset. The usage was overwhelmingly cached input, so this does not look consistent with the prior effective capacity of the same Pro plan and workflow. ### Measured usage for 2026-08-01 ```text Input tokens: 2,724,979 Output tokens: 212,314 Cache write: 0 Cache read: 72,313,088 Total tokens: 75,250,381 ccusage API-equivalent: $56.15 ``` Approximately **96.1% of the total tokens were cache reads**. Model breakdown: ```text gpt-5.6-sol Input: 1,372,881 Output: 199,594 Cache read: 50,787,584 Total: 52,360,059 gpt-5.5 Input: 1,352,098 Output: 12,720 Cache read: 21,525,504 Total: 22,890,322 ``` ### Account/session evidence ```text Weekly limit remaining: 74% Next reset: Aug 8 at 14:33 Session ID: 019fb8e8-c151-7e91-b5c1-aebf413a1a3d Context window: 227K used / 258K ``` At the observed rate, the full weekly Pro pool would correspond to only about 289M tokens for this same usage mix, which is roughly half the effective capacity observed before the August 1 reset. ### Expected behavior A global reset should restart the same Pro entitlement and accounting behavior. It should not silently reduce the effective weekly capacity by roughly 2x for an unchanged workflow. Cached input should be charged using the documented cached-input weighting, and internal retries, automatic review/guardian tasks, delayed reconciliation, or duplicate attribution should not unexpectedly consume a large share of the weekly allowance. ### Requested investigation Please inspect the server-side usage ledger for the session above and confirm: 1. The exact credits charged for uncached input, cached input, and output. 2. Whether any internal automatic tasks, retries, subagents, or delayed usage were also charged. 3. Whether the Pro entitlement or model weighting changed after the August 1 global reset. 4. Whether usage was duplicated or reconciled late. 5. Whether incorrectly consumed weekly allowance can be restored. Screenshots of the token breakdown and the 74%-remaining weekly meter are available if needed.", "url": "https://github.com/openai/codex/issues/36488", "createdAt": "2026-08-01T15:05:54Z", "updatedAt": "2026-08-12T14:56:10Z", "timestamp": "2026-08-12T14:56:10Z", "metrics": { "reactions": 0, "comments": 3 }, "labels": [ "bug", "rate-limits" ], "author": "zkhrvv", "state": "open", "assignees": [], "change": "updated" }, { "id": "github:openai/codex:issue:36640", "source": "github", "group": "coding-agent-infrastructure", "project": "openai/codex", "kind": "issue", "title": "Expose active model and reasoning effort to Codex voice/mobile sessions", "text": "## Summary When using Codex through voice or mobile, the active model and reasoning-effort setting are not visible to the agent. The user may be away from their desktop and unable to inspect the model picker, while the agent also cannot read the active session configuration or operate the Codex app through Computer Use. This makes it impossible to answer a basic question accurately: which model and reasoning effort are active in the current conversation? ## Actual behavior - The session’s model and reasoning effort are not exposed to the tool-backed agent context. - The agent can only describe documented defaults, not confirm the active setting for the current session. - Desktop automation cannot operate the Codex app to inspect the picker. - On mobile/voice, the user may not have access to the desktop control at all. ## Expected behavior Expose a read-only, structured session-metadata capability that returns at least: - active model - reasoning effort - speed or service tier, when relevant - whether the setting is inherited, defaulted, or explicitly selected This should be available to the active Codex agent and ideally visible in mobile/voice UI as well. ## User impact Users cannot verify whether they are using the intended model or reasoning level while away from the desktop. It also prevents the agent from giving a trustworthy answer about its current configuration. ## Related This appears adjacent to #32291, which requests resolved model and reasoning metadata for tool-backed child sessions. This report concerns visibility of the currently active parent session, particularly for mobile and voice use.", "url": "https://github.com/openai/codex/issues/36640", "createdAt": "2026-08-02T23:49:38Z", "updatedAt": "2026-08-12T19:50:46Z", "timestamp": "2026-08-12T19:50:46Z", "metrics": { "reactions": 0, "comments": 3 }, "labels": [ "enhancement", "app", "session" ], "author": "Hamzablm", "state": "open", "assignees": [] }, { "id": "github:openai/codex:issue:36790", "source": "github", "group": "coding-agent-infrastructure", "project": "openai/codex", "kind": "issue", "title": "[App] Add user-confirmed model and reasoning routing for persistent task creation", "text": "### What variant of Codex are you using? Codex App (Desktop), with persistent user-visible tasks created through `codex_app.create_thread`. The local Codex host used for verification is `codex-cli 0.146.0`. ### What feature would you like to see? Add a first-class, human-in-the-loop model and reasoning routing flow for persistent task creation. The desired flow is: 1. The coordinating agent evaluates the proposed task. 2. It proposes an exact model and reasoning-effort pair for that task. 3. Codex shows the proposal to the user in a structured confirmation/edit UI. 4. Only after the user approves or edits the pair does Codex create the persistent task. 5. The created task records the proposed, approved, and effective model/reasoning values. For multiple tasks, the app should support confirming a task-to-model/reasoning mapping as one batch before creation. #### Why this is needed The current `create_thread` tool accepts `model` and `thinking`, but its agent guidance says not to specify a model unless the user explicitly requests a specific model. Otherwise, the fields are omitted and each new task inherits the configured global default. That is safe, but it prevents an orchestrator from applying task-specific routing unless the user already knows which exact model to request. In practice, a user may want the agent to make the technical recommendation while retaining final control over cost/capability. In one observed workflow, a coordinator classified several materially different tasks but omitted `model` and `thinking` because no exact model had been explicitly requested. All persistent tasks therefore inherited the same global default (`gpt-5.6-sol`, `medium`) instead of using the intended per-task routing. #### Existing configuration does not cover this surface The current config schema provides: - `agents.default_subagent_model` - `agents.default_subagent_reasoning_effort` - `features.multi_agent_v2.expose_spawn_agent_model_overrides` Those settings apply to spawned subagents, not persistent user-visible App tasks created through `create_thread`. The managed `[models.new_thread]` defaults in `requirements.toml` are static defaults, not a per-task recommendation and approval flow. I could not find a `config.toml` option for user-confirmed persistent-task routing. An optional configuration shape could be something like: ```toml [tasks] model_routing = \"confirm\" # default | confirm ``` The exact name is not important; the important behavior is that `confirm` permits the agent to propose a model/reasoning pair but requires explicit user approval before task creation. #### Acceptance criteria - The agent may propose an exact supported model and reasoning effort for a new persistent task. - The user can approve or edit both values before creation. - No persistent task is created until confirmation is received. - Batch creation presents a clear task-to-model/reasoning mapping. - The approved values are passed explicitly to `create_thread`. - The resulting task exposes the effective model and reasoning effort for auditability. - If the approved pair is unavailable on the destination host, Codex asks for a new choice instead of silently falling back to the global default. - The feature remains opt-in and preserves the user's final authority. ### Additional information This is distinct from subagent model routing: - #31814 covered model overrides for Multi-Agent V2 subagent spawns. - #32749 exposed model/reasoning overrides for that `spawn_agent` surface. - #26767 added global subagent runtime defaults. It is also narrower than #14923, which requested first-class cross-thread orchestration. Codex App now exposes `create_thread`; this request concerns the missing user-confirmed model/reasoning selection step when creating those persistent tasks. Official config schema: https://developers.openai.com/codex/config-schema.json", "url": "https://github.com/openai/codex/issues/36790", "createdAt": "2026-08-03T19:50:25Z", "updatedAt": "2026-08-12T19:33:40Z", "timestamp": "2026-08-12T19:33:40Z", "metrics": { "reactions": 0, "comments": 1 }, "labels": [ "enhancement", "app", "session" ], "author": "ginishuh", "state": "open", "assignees": [] }, { "id": "github:openai/codex:issue:36824", "source": "github", "group": "coding-agent-infrastructure", "project": "openai/codex", "kind": "issue", "title": "Codex Desktop: switching Local to Cloud cannot switch back; summary panel fails to render", "text": "## Summary In Codex Desktop on macOS, switching a task from **Local** to **Cloud** in the side-panel environment selector can leave the task stuck in Cloud. The selector no longer lets me switch the task back to Local. At the same time, the side panel displays **\"Summary panel couldn't render.\"** This blocks returning the task to the local workspace. ## Steps to reproduce 1. Open a task in Codex Desktop that is running locally. 2. In the side panel, change its execution environment from **Local** to **Cloud**. 3. Attempt to change the same setting back from **Cloud** to **Local**. 4. Open or view the summary side panel. ## Expected behavior The environment selector should continue to allow switching back to **Local** (or clearly explain why Local is unavailable). The summary panel should render normally. ## Actual behavior The task remains in Cloud and cannot be switched back to Local. The summary side panel shows: > Summary panel couldn't render ## Environment - Platform: macOS - Codex Desktop version: `26.727.51351` ## Screenshot A screenshot showing the failed summary panel is available and can be attached.", "url": "https://github.com/openai/codex/issues/36824", "createdAt": "2026-08-04T02:09:17Z", "updatedAt": "2026-08-13T02:20:44Z", "timestamp": "2026-08-13T02:20:44Z", "metrics": { "reactions": 2, "comments": 1 }, "labels": [ "bug", "app", "session" ], "author": "kerryzl77", "state": "open", "assignees": [] }, { "id": "github:openai/codex:issue:36922", "source": "github", "group": "coding-agent-infrastructure", "project": "openai/codex", "kind": "issue", "title": "Pg up and Pg down keys doesn't work properly in Codex CLI", "text": "### What version of Codex CLI is running? codex-cli 0.146.0 ### What subscription do you have? Plus ### Which model were you using? _No response_ ### What platform is your computer? Linux 7.1.5-101.fc43.x86_64 x86_64 ### What terminal emulator and version are you using (if applicable)? Gnome ### Codex doctor report ```json ``` ### What issue are you seeing? When I press `pg down` or `pg up`, the thread just scroll to the end. ### What steps can reproduce the bug? 1. Start a thread or resume a past thread 2. Press `pg up` or `pg down` key ### What is the expected behavior? When pressing `pg up` or `pg down` the scroll should move up or move down in a convenient size in relation to the available height and not always going to the end. ### Additional information _No response_", "url": "https://github.com/openai/codex/issues/36922", "createdAt": "2026-08-04T16:42:32Z", "updatedAt": "2026-08-13T14:49:22Z", "timestamp": "2026-08-13T14:49:22Z", "metrics": { "reactions": 0, "comments": 1 }, "labels": [ "bug", "TUI", "CLI" ], "author": "rafaself", "state": "closed", "assignees": [] }, { "id": "github:openai/codex:issue:36929", "source": "github", "group": "coding-agent-infrastructure", "project": "openai/codex", "kind": "issue", "title": "Codex Desktop: updating a shared Business workspace plugin fails because upload-url returns 404", "text": "### What version of the Codex App are you using (From “About Codex” dialog)? 26.727.6591.0 ### What subscription do you have? ChatGPT Business ### What platform is your computer? Microsoft Windows NT 10.0.26200.0 x64 ### What issue are you seeing? Codex Desktop cannot update an existing locally built plugin that is already shared with a ChatGPT Business workspace. The Share dialog correctly detects that the shared version is outdated and displays **Update**, but selecting it consistently fails with: ```text save remote plugin share: remote plugin catalog request to https://chatgpt.com/backend-api/public/plugins/workspace/upload-url failed with status 404 Not Found: {\"detail\":\"Not found\"} ``` The existing shared version remains active. The updated bundle is not published. ### What steps can reproduce the bug? 1. Sign in to a ChatGPT Business workspace in Codex Desktop as the workspace owner. 2. Install a local plugin and share it with one or more workspace members. 3. Bump the local plugin version and keep the same plugin identity/App MCP. 4. Open **Plugins > Created by you > the existing shared plugin**. 5. Open **Share**. 6. Confirm the UI says the shared version is outdated. 7. Select **Update**. 8. Observe the 404 error above. Reproduced multiple times, including after fully restarting Codex Desktop and switching away from and back to the Business workspace. Example local plugin manifest version: `1.0.3`. ### What is the expected behavior? Codex should request an upload URL, upload the updated plugin bundle, and update the existing remote share while preserving its plugin identity, connected App MCP, access list, and installations. ### Additional information The current client implementation intentionally POSTs to `/public/plugins/workspace/upload-url` before uploading the bundle: https://github.com/openai/codex/blob/main/codex-rs/core-plugins/src/remote/share.rs The 404 occurs before the bundle PUT, so plugin validation and upload never start. This points to a backend provisioning/route availability mismatch for the Business workspace rather than a plugin bundle validation error. Related issue #22885 reports the same backend upload-url route returning 404 through another plugin-sharing path: https://github.com/openai/codex/issues/22885 Official Codex feedback tracking ID: `no-active-thread-019fcdbd-60b6-7640-afd2-e97cf3cf168e` No tokens, remote plugin identifiers, plugin contents, or customer data are included.", "url": "https://github.com/openai/codex/issues/36929", "createdAt": "2026-08-04T17:07:54Z", "updatedAt": "2026-08-12T18:03:37Z", "timestamp": "2026-08-12T18:03:37Z", "metrics": { "reactions": 1, "comments": 1 }, "labels": [ "bug", "windows-os", "app", "skills", "connectivity" ], "author": "thiagovbdiniz", "state": "open", "assignees": [] }, { "id": "github:openai/codex:issue:36953", "source": "github", "group": "coding-agent-infrastructure", "project": "openai/codex", "kind": "issue", "title": "Browser site permission remains blocked after rule deletion and restart", "text": "## Description Browser Use continues to block access to `https://forum.vgd.ru` with the following error: > A saved user permission setting blocks this action. However, no site-specific permission exists in the Codex settings. ## Steps to reproduce 1. Open Codex on Windows. 2. Go to **Settings → Browser**. 3. Set **Confirmation** to **Always ask**. 4. Delete all site-specific rules for `https://forum.vgd.ru`. 5. Open or explicitly attach a Chrome tab displaying `https://forum.vgd.ru`. 6. Ask Codex to read the page. ## Actual behavior Access is immediately rejected because of a supposedly saved user preference. No permission prompt appears. ## Expected behavior Codex should display a new permission prompt because no site-specific rule exists. ## Troubleshooting already attempted - Explicitly allowed viewing, downloading, and uploading for the site. - Removed the custom site permission completely. - Set confirmation to **Always ask**. - Refreshed and reopened the page in a new Chrome tab. - Restarted Codex. - Restarted the computer. - Explicitly attached the Chrome tab to the Codex conversation. The issue persists after all these steps. ## Environment - Windows - Google Chrome - ChatGPT browser extension version: `1.2.27236.6274` - Affected site: `https://forum.vgd.ru`", "url": "https://github.com/openai/codex/issues/36953", "createdAt": "2026-08-04T19:26:46Z", "updatedAt": "2026-08-13T14:17:29Z", "timestamp": "2026-08-13T14:17:29Z", "metrics": { "reactions": 0, "comments": 4 }, "labels": [ "bug", "windows-os", "app", "browser" ], "author": "dmitryklimansky", "state": "open", "assignees": [] }, { "id": "github:openai/codex:issue:37002", "source": "github", "group": "coding-agent-infrastructure", "project": "openai/codex", "kind": "issue", "title": "Unable to install after clicking Update in the Codex app today", "text": "### What version of the Codex App are you using (From “About Codex” dialog)? 无 ### What subscription do you have? 无 ### What platform is your computer? macos12 ### What issue are you seeing? \"Image\" 我电脑是macbook pro 2020 intel系统是macos12今天codex app点更新安装时候报错报需要macos13以上，这个能不能修复，或者我怎么回退上一个版本 ### What steps can reproduce the bug? Feedback ID: no-active-thread-019fcf8f-6d45-7f60-a518-034df7017c48 ### What is the expected behavior? _No response_ ### Additional information _No response_", "url": "https://github.com/openai/codex/issues/37002", "createdAt": "2026-08-05T01:41:29Z", "updatedAt": "2026-08-13T01:49:35Z", "timestamp": "2026-08-13T01:49:35Z", "metrics": { "reactions": 1, "comments": 28 }, "labels": [ "bug", "app" ], "author": "ytc301", "state": "closed", "assignees": [] }, { "id": "github:openai/codex:issue:37018", "source": "github", "group": "coding-agent-infrastructure", "project": "openai/codex", "kind": "issue", "title": "[Windows regression] Selected task with multiple active subagents freezes the app", "text": "### What version of the Codex App are you using? Affected version: `26.730.61309`. The issue appeared after today's update from `26.727.51351`. ### What subscription do you have? Pro ### What platform is your computer? Windows 11 x64 (`10.0.26200`). The affected task uses a WSL2 workspace. ### What issue are you seeing? After today's update, selecting a Codex task with multiple active subagents makes the app severely sluggish. With 12 active subagents, hover states stopped responding reliably and typing into text boxes became heavily delayed. On one attempt to check back in on the affected task, the app froze completely for approximately 60–90 seconds before recovering. The rest of Windows remained responsive. Switching to another chat in the same app restored normal hover and typing performance while the subagents continued running. The slowdown therefore appears tied to displaying the affected task, rather than to the overall system workload. This is different from the system-wide input lag in #28855. ### Steps to reproduce 1. Run several subagents concurrently in a Codex task (12 in this case). 2. Keep that task selected. 3. Hover over controls or type into a text box. 4. Observe severe UI lag; checking back in on the task may freeze the app completely for 60–90 seconds. 5. Switch to another chat without stopping the subagents. 6. Observe normal UI responsiveness. ### Expected behaviour The selected task should remain responsive while subagents run.", "url": "https://github.com/openai/codex/issues/37018", "createdAt": "2026-08-05T03:05:04Z", "updatedAt": "2026-08-12T21:23:53Z", "timestamp": "2026-08-12T21:23:53Z", "metrics": { "reactions": 0, "comments": 2 }, "labels": [ "bug", "windows-os", "app", "subagent", "performance" ], "author": "kendonB", "state": "open", "assignees": [] }, { "id": "github:openai/codex:issue:37023", "source": "github", "group": "coding-agent-infrastructure", "project": "openai/codex", "kind": "issue", "title": "ide context not work for codex on cursor", "text": "### What version of Codex CLI is running? v0.146.0 ### What subscription do you have? enterprise ### Which model were you using? _No response_ ### What platform is your computer? _No response_ ### What terminal emulator and version are you using (if applicable)? _No response_ ### Codex doctor report ```json ``` ### What issue are you seeing? Have already install codex extension on cursor, and reload window, but codex still can not have ide context. ### What steps can reproduce the bug? Uploaded thread: 019fd024-8460-7f51-84b8-28148cc8fb72 ### What is the expected behavior? _No response_ ### Additional information _No response_", "url": "https://github.com/openai/codex/issues/37023", "createdAt": "2026-08-05T04:23:01Z", "updatedAt": "2026-08-12T21:30:07Z", "timestamp": "2026-08-12T21:30:07Z", "metrics": { "reactions": 0, "comments": 1 }, "labels": [ "bug", "extension" ], "author": "habaohaba", "state": "open", "assignees": [] }, { "id": "github:openai/codex:issue:37029", "source": "github", "group": "coding-agent-infrastructure", "project": "openai/codex", "kind": "issue", "title": "[Windows][26.730.7989.0] Computer Use fails before app selection with EPERM lstat on Codex runtime", "text": "### What version of the Codex App are you using (From “About Codex” dialog)? 26.730.7989.0 ### What subscription do you have? ChatGPT subscription (exact tier not displayed in Codex App) ### What platform is your computer? Microsoft Windows NT 10.0.26200.0 x64 ### What issue are you seeing? ## Summary After updating the Codex Windows desktop app, **Computer Use / Any App fails before it can enumerate or control any desktop application**. This is not specific to Claude: a harmless Notepad test fails at the same initialization point. Exact error (username redacted): ~~~text EPERM: operation not permitted, lstat 'C:\\Users\\\\AppData\\Local\\OpenAI\\Codex' ~~~ The failure happens while importing the bundled `@oai/sky` package, before `list_windows()` or any app-specific operation can run. ## Impact - Any App cannot control Claude, Notepad, or any other Windows application. - No target application is opened or touched. - Browser/in-app-browser functionality can still work, so the failure is specific to the Computer Use runtime initialization path. ## Troubleshooting already completed - Repaired the Codex app from Windows Advanced options. - Restarted Codex. - Rebooted Windows. - Verified the affected directory exists. - Verified the signed-in Windows user has Full Control on the directory. - Retested with a fresh Node REPL kernel. - Observed bundled Computer Use plugin cache refresh from `26.730.61309` to `26.730.61639`; the same EPERM remains. The problem started immediately after the Codex desktop update. ## Relevant related reports - #37013: same Codex AppX version and the earlier `26.730.61309` Computer Use plugin, but a different Computer Use transport/context failure. - #18861: closely matching Windows sandbox behavior where basic Node runs but `lstat`/`realpath` returns EPERM. - #23884: plugin/browser diagnostics fail with `EPERM: operation not permitted, lstat 'C:\\Users\\...'` after reinstall. This looks like a Windows AppContainer/sandbox runtime path regression rather than a target-app permission problem. ### What steps can reproduce the bug? 1. Install or update Codex Desktop for Windows to `26.730.7989.0`. 2. Enable the bundled Computer Use / Any App feature. 3. Start a fresh Codex task and request control of a harmless application such as Notepad. 4. The documented initialization runs: ~~~js if (!globalThis.sky) { const { sky } = await import(\"@oai/sky\"); globalThis.sky = sky; } ~~~ 5. The import fails immediately with: ~~~text EPERM: operation not permitted, lstat 'C:\\Users\\\\AppData\\Local\\OpenAI\\Codex' ~~~ The failure occurs before `sky.list_windows()` and before any desktop app is selected. Repairing the app, restarting Codex, and rebooting Windows do not resolve it. ### What is the expected behavior? `@oai/sky` should load successfully, `sky.list_windows()` should enumerate available windows, and Computer Use should then request/obey normal per-app authorization before interacting with Notepad or another selected application. A user-level Full Control ACL on the extracted Codex runtime should not still produce EPERM inside the app's own sandboxed Computer Use loader. ### Additional information - Codex AppX: `26.730.7989.0` x64 - Windows: `Microsoft Windows NT 10.0.26200.0 x64` - Computer Use plugin observed: `26.730.61309`, later `26.730.61639` after cache refresh - The path and account name above are deliberately redacted. - Subscription tier is not displayed in the Codex app used for this report. - Session ID omitted from this public report for privacy; it can be supplied privately if maintainers request it. Recent issue search shows multiple new Windows/Computer Use reports between Aug 2-5, 2026, including #37013 on the exact same AppX version. This report is separate because the failure occurs even earlier, during the first `@oai/sky` import.", "url": "https://github.com/openai/codex/issues/37029", "createdAt": "2026-08-05T05:18:17Z", "updatedAt": "2026-08-13T13:38:01Z", "timestamp": "2026-08-13T13:38:01Z", "metrics": { "reactions": 3, "comments": 11 }, "labels": [ "bug", "windows-os", "sandbox", "app", "computer-use" ], "author": "Ahmedmabdallah484", "state": "open", "assignees": [] }, { "id": "github:openai/codex:issue:37042", "source": "github", "group": "coding-agent-infrastructure", "project": "openai/codex", "kind": "issue", "title": "Codex Desktop: completed subagents restore as Active after reload", "text": "## Version and platform - Codex Desktop for Windows x64 - Store package `OpenAI.Codex 26.730.8199.0` - Installed `app.asar` SHA-256: `acba5f408b7c6c909ffbfdf3c7d3f10660897bfbbb10f916a78505986b44b772` ## Bug After Desktop reloads a task with a long subagent history, completed child agents are restored under **Active** instead of **Done**. This is not a small count drift. In one reproducible parent task: | Evidence | Count | |---|---:| | Direct child spawn edges | 126 | | Child rollout ends in `task_complete` | 117 | | Child rollout ends in `turn_aborted` | 6 | | Nonterminal or unresolved | 3 | | Desktop panel shows Active | 109 | | Desktop panel shows Done | 17 | At least 100 durably completed children are therefore displayed as active. The underlying child records are not lost. A direct `thread/read` for an affected child returns `thread.status = notLoaded` and a latest turn whose status is `completed`. ## Reproduction 1. Open a Desktop task. 2. Spawn and complete enough subagents for the parent to retain several historical children. 3. Restart Desktop or otherwise cold-hydrate that task. 4. Open the Subagents panel. 5. Observe completed children under Active. 6. Directly read one of those children: the runtime thread status is `notLoaded`, while its latest durable turn is `completed`. ## Root cause The shipped renderer's descendant discovery uses: ```text thread/list ancestorThreadId= sourceKinds=[\"subAgentThreadSpawn\"] useStateDbOnly=true ``` Stored children that are not loaded in the current app-server process correctly arrive with runtime `ThreadStatus.notLoaded`. The renderer then combines that with the parent's historical `subAgentActivity` state. Parent activity has `started`, `interacted`, and `interrupted`, but no durable `completed` activity kind. As a result, the stale parent-side `running` reference wins and the child is projected as Active. The renderer already has a correct latest-turn fallback for descendants that were observed but missing from `thread/list`: it reads turn history and maps terminal latest turns away from Active. That fallback is not applied to descendants that were successfully returned by the state-DB list, which is exactly the cold-reload case above. `thread_spawn_edges.status = open` is not a runtime status and should not be changed or interpreted as Active/Done. ## Minimal safe fix During descendant discovery, hydrate only listed children whose runtime status is `notLoaded`: ```text thread/turns/list threadId= cursor=null limit=1 sortDirection=desc itemsView=notLoaded ``` Projection: - latest `completed` -> Done - latest `failed` or `interrupted` -> existing failure/interruption policy; never Active - latest `inProgress` returned by the current app-server -> Active; the server normalizes stale non-running `inProgress` turns to `interrupted`, so this represents the list-to-live race - no turn/read failure -> remain unknown and stay out of Active; do not guess Done - already loaded runtime `active`, `idle`, or `systemError` records are not queried or overwritten - live `thread/status/changed=active` evidence wins over the hydrated historical snapshot To keep the large-history path bounded: - use one class-wide semaphore to cap concurrent latest-turn reads (a local patch uses 8), - deduplicate only simultaneous in-flight reads for the same `(threadId, updatedAt)`, - remove settled results so second-resolution `updatedAt` cannot make same-second lifecycle changes stale and the cache cannot grow without bound, - return only one latest turn over the wire, - do not repurpose spawn-edge status. Performance caveat: in the current legacy app-server path, `thread/turns/list limit=1` still reconstructs the child's full rollout internally before truncating the response. A renderer-only correction therefore performs up to one full replay per cold `notLoaded` child and can repeat that work on later discovery cycles. The production fix should expose an indexed latest lifecycle projection in descendant listing or use indexed turn metadata; the renderer candidate must not be presented as performance-proven on a 126-child live history until that cost is measured. ## Regression coverage requested 1. Cold restart: parent has only `started/interacted`; child runtime is `notLoaded`; latest turn is `completed` -> Done 1, Active 0. 2. A list-to-live race returns latest `inProgress` from the current app-server -> Active 1, Done 0. 3. Latest turn is `interrupted` or `failed` -> not Active; keep the terminal turn available to the existing UI policy. 4. Missing/corrupt history -> unknown, not guessed Done. 5. A same-second empty/interrupted read followed by completed is reread and projected Done. 6. Simultaneous reads for the same generation are deduplicated, but a later discovery rereads it. 7. Loaded runtime `active`, `idle`, and `systemError` are never queried or overwritten. 8. Two simultaneous large discovery calls share a global concurrency cap of 8. 9. Mixed 126-child fixture -> Done 117, Active 2, interrupted excluded 6, unknown excluded 1. 10. Real legacy 126-child hydration -> measure wall time, peak memory, and renderer responsiveness, or use an indexed backend projection that avoids full rollout replay. A byte-guarded local renderer patch passes a regression that executes the exact injected production hydration methods, the shipped `HFs` projection, and the shipped side-panel Done/Active predicates. The 126-child fixture produces Done 117 and Active 2; six interrupted and one unknown child stay out of Active. The signed Store package was not modified.", "url": "https://github.com/openai/codex/issues/37042", "createdAt": "2026-08-05T06:57:54Z", "updatedAt": "2026-08-13T10:01:31Z", "timestamp": "2026-08-13T10:01:31Z", "metrics": { "reactions": 2, "comments": 5 }, "labels": [ "bug", "windows-os", "app", "subagent", "Papercuts 2026" ], "author": "molamola-git", "state": "open", "assignees": [] }, { "id": "github:openai/codex:issue:37059", "source": "github", "group": "coding-agent-infrastructure", "project": "openai/codex", "kind": "issue", "title": "macOS: same-version Chrome plugin cache reconciliation deletes chrome/latest while the plugin remains current", "text": "### What version of the Codex App are you using (From “About Codex” dialog)? ChatGPT desktop app `26.730.61639` (build `6234`, bundle identifier `com.openai.codex`). The bundled `chrome@openai-bundled` plugin is also version `26.730.61639`. ### What subscription do you have? ChatGPT Pro ### What platform is your computer? ~~~text Darwin 25.5.0 arm64 arm Google Chrome 150.0.7871.188 ChatGPT Chrome Extension 1.2.27236.6274_0 ~~~ ### What issue are you seeing? On macOS, a same-version bundled-plugin cache reconciliation can replace the entire Chrome plugin cache root and delete the runtime-created `latest` symlink, even though the current versioned plugin directory remains complete and the plugin is still reported as installed, enabled, and current. Before reconciliation: ~~~text ~/.codex/plugins/cache/openai-bundled/chrome/ ├── 26.730.61639/ └── latest -> 26.730.61639 ~~~ After reconciliation, without an app or plugin version change: ~~~text ~/.codex/plugins/cache/openai-bundled/chrome/ └── 26.730.61639/ ~~~ The versioned directory still exists, but `latest` is absent. The plugin manager still reports: ~~~text chrome@openai-bundled installed, enabled 26.730.61639 ~~~ The Chrome Native Messaging manifest remains syntactically valid and continues to point through the missing alias: ~~~text /Users//.codex/plugins/cache/openai-bundled/chrome/latest/extension-host/macos/arm64/ChatGPT for Chrome ~~~ Therefore, once `latest` is deleted, a fresh native-host launch resolves to a nonexistent path. This can be temporarily masked when the native host and its communication channel are already running: an existing connection may continue controlling Chrome without resolving the manifest again. Manually recreating the current-version symlink restores a fresh Chrome connection: ~~~sh cd ~/.codex/plugins/cache/openai-bundled/chrome ln -s 26.730.61639 latest ~~~ After this repair, Codex successfully opened `https://example.com/` in the user's Chrome and read the page title and heading. A later bundled-plugin cache rebuild deleted the manually repaired symlink again, so the workaround is not durable. This leaves three layers inconsistent: 1. The complete versioned plugin directory exists. 2. The plugin manager reports the plugin installed/enabled/current. 3. The Native Messaging manifest points through a missing `latest` alias. ### What steps can reproduce the bug? 1. Install and enable the bundled Chrome plugin and the ChatGPT Chrome Extension on macOS. 2. Confirm that the cache contains both `chrome/26.730.61639/` and `chrome/latest -> 26.730.61639`. 3. Confirm that the Chrome Native Messaging manifest points to `chrome/latest/.../ChatGPT for Chrome`. 4. Resume/switch desktop tasks or open the plugin UI and allow the bundled-plugin background reconciliation to run. In the observed runs, all bundled plugin version directories were recreated together without a version change. The desktop log does not emit a dedicated cache-swap event, so the exact initiating UI request is not yet proven. 5. Inspect the cache again. 6. Observe that `chrome/26.730.61639/` remains complete, but `chrome/latest` has been deleted. 7. Observe that the plugin still appears installed, enabled, and current. 8. Recreate `latest` as a symlink to `26.730.61639` and establish a fresh Chrome connection. Chrome control works. 9. Allow another bundled-plugin reconciliation to run. 10. Observe that the manually repaired `latest` symlink is deleted again. This was observed repeatedly on the same desktop/plugin version; no application upgrade occurred between deletion events. ### What is the expected behavior? Bundled-plugin reconciliation should preserve or atomically recreate every runtime artifact required by the installed plugin. - If Native Messaging manifests use `chrome/latest`, that alias should always point to the active complete plugin version. - A plugin should not be reported as current when its registered native-host executable does not resolve to an existing executable. - The versioned directory, active alias, Native Messaging manifest, and installed-plugin state should be reconciled as one recoverable transaction. - A manually repaired current-version alias should not be removed by a same-version background refresh. - Preferably, a long-lived native host should be registered from a stable location outside a replaceable plugin-cache root. ### Additional information #### Related but not duplicate - #31904 reports a dangling `latest` symlink that still points to a removed old plugin version, together with a stale executable name after an update. - #32238 primarily reports Chrome for Testing/Chromium selection and also notes an alias still pointing to an old removed version. - #32706 and #22114 report Windows file-lock/partial-update transaction failures. - #24296 describes the broader Windows architectural risk of running the native host from a mutable plugin cache. - #18863 covers symlinks inside plugin source trees being skipped during copying. This report is specifically about macOS, standard Chrome, no version transition, and the `latest` sibling itself being deleted after a successful same-version plugin-root rebuild. The current version directory remains present and the plugin remains reported as current. #### Possible source-level cause This is a hypothesis based on the current public source, separate from the directly observed filesystem behavior: - `replace_plugin_root_atomically` stages only the versioned plugin directory, then renames the existing complete plugin root to a backup and renames the staged root into place: https://github.com/openai/codex/blob/main/codex-rs/core-plugins/src/store.rs#L605-L697 - The runtime-created sibling `latest` alias is not included in that staged root. - `active_plugin_version` considers directory entries and can still find the versioned directory while ignoring the missing symlink: https://github.com/openai/codex/blob/main/codex-rs/core-plugins/src/store.rs#L169-L181 The filesystem deletion, incorrect current status, manifest path, temporary symlink repair, successful Chrome control after repair, and repeated deletion were directly observed. The exact background caller that initiated the successful root replacement is inferred from the simultaneous bundled-plugin rebuild and current Store implementation. All usernames, workspace paths, prompts, account data, private URLs, logs, and task/session identifiers have been omitted.", "url": "https://github.com/openai/codex/issues/37059", "createdAt": "2026-08-05T08:29:50Z", "updatedAt": "2026-08-13T02:24:17Z", "timestamp": "2026-08-13T02:24:17Z", "metrics": { "reactions": 0, "comments": 7 }, "labels": [ "bug", "app", "skills", "browser" ], "author": "STSNaive", "state": "open", "assignees": [] }, { "id": "github:openai/codex:issue:37197", "source": "github", "group": "coding-agent-infrastructure", "project": "openai/codex", "kind": "issue", "title": "MultiAgentV2 plaintext support in 0.147.0-alpha.1 does not complete cross-provider task delivery", "text": "## Summary [#35845](https://github.com/openai/codex/pull/35845), included in `0.147.0-alpha.1`, added support for processing plaintext collaboration tool messages. However, that change covers the receiving path only when plaintext has already been selected upstream. It does not provide an end-to-end way for an OpenAI parent to select plaintext delivery when spawning a child backed by a third-party provider. As a result, the cross-provider failure reported in [#34833](https://github.com/openai/codex/issues/34833) remains reproducible on a source baseline of `0.147.0-alpha.4`: the child is created with the intended role, provider, and model, but cannot consume its initial task because the assignment is still delivered as provider-specific encrypted content. ## Environment - Windows - Codex Desktop - Source baseline: `codex-cli 0.147.0-alpha.4` - Parent: OpenAI provider - Child: third-party provider using an OpenAI-compatible API - Multi-agent implementation: V2 - Direct requests to the third-party provider succeed Provider names, endpoints, credentials, account information, and third-party model identifiers have been intentionally omitted. ## Observed behavior 1. Enable MultiAgentV2. 2. Configure a registered child role backed by a third-party provider. 3. Start an OpenAI-backed parent. 4. Invoke `spawn_agent` for that child role. 5. Codex resolves the intended child role, provider, and model and creates the child. 6. The child cannot read the initial assignment and therefore cannot begin the task. The same third-party provider succeeds when invoked directly, which isolates the failure to the MultiAgentV2 provider boundary rather than authentication, networking, or model availability. ## Why the 0.147.0-alpha.1 fix is incomplete The implementation added by #35845 preserves `encrypted_function_args` and introduces `ToolCallSource::DirectPlaintextMessage`. A collaboration call is classified as plaintext only when all of the following are true: - the namespace is exactly `collaboration`; - the tool is `spawn_agent`, `send_message`, or `followup_task`; - `encrypted_function_args == Some([])`. When that marker is present, the handlers construct a structured plaintext agent message. Otherwise, they retain the existing encrypted path. The remaining gap is that the MultiAgentV2 tool schemas still unconditionally apply `.with_encrypted()` to the message fields for `spawn_agent`, `send_message`, and `followup_task`. An OpenAI parent therefore normally produces actual encrypted arguments rather than the empty marker required by `DirectPlaintextMessage`. The call is classified as `Direct`, and the handler still uses: ```text InterAgentCommunication::new_encrypted(...) ``` The third-party child then receives content it cannot decrypt or interpret. The alpha.1 implementation also has the following limitations for this topology: - plaintext classification is hard-coded to the `collaboration` namespace; - a configured custom namespace cannot enter the plaintext branch; - providers without namespace-tool support cannot match that condition; - there is no provider-aware delivery selection; - there is no explicit configuration to request plaintext delivery; - encrypted delivery to a third-party child is not rejected before the unusable child is created. The relevant schema, classification, and message-construction behavior remains materially unchanged between `0.147.0-alpha.1` and `0.147.0-alpha.4`. Simply removing `.with_encrypted()` is also insufficient. A modified plaintext schema under the reserved `collaboration` namespace is rejected by the OpenAI API because reserved collaboration functions must match the configured schema exactly. A complete fix therefore also needs a supported non-reserved namespace or an upstream-compatible schema mechanism. ## Local source-level fix path I implemented and validated an opt-in, backwards-compatible delivery policy across the following source paths. ### Configuration and schema - `codex-rs/features/src/feature_configs.rs` - `codex-rs/features/src/lib.rs` - `codex-rs/core/src/config/mod.rs` - `codex-rs/core/config.schema.json` The local configuration shape is: ```toml [features.multi_agent_v2] enabled = true message_delivery = \"plaintext\" tool_namespace = \"agents\" ``` `encrypted` remains the default. ### Tool schemas - `codex-rs/core/src/tools/handlers/multi_agents_spec.rs` The encrypted marker is applied conditionally to the message fields for `spawn_agent`, `send_message`, and `followup_task`. ### Tool planning and call classification - `codex-rs/core/src/tools/spec_plan.rs` - `codex-rs/core/src/tools/router.rs` - `codex-rs/core/src/tools/parallel.rs` Plaintext mode classifies the relevant calls as `DirectPlaintextMessage` using the configured tool namespace rather than only the hard-coded `collaboration` namespace. ### MultiAgentV2 message handling - `codex-rs/core/src/tools/handlers/multi_agents_v2.rs` - `codex-rs/core/src/tools/handlers/multi_agents_v2/spawn.rs` - `codex-rs/core/src/tools/handlers/multi_agents_v2/send_message.rs` - `codex-rs/core/src/tools/handlers/multi_agents_v2/followup_task.rs` - `codex-rs/core/src/stream_events_utils.rs` Plaintext mode reuses the structured `input_text` path. If an encrypted task is about to be delivered to a non-OpenAI child, the spawn fails before child creation with an actionable configuration error. ## Validation results - Feature configuration tests: 34/34 passed. - Targeted MultiAgentV2 tests: 74/74 passed. - Plaintext tool-schema tests passed. - Custom and unnamespaced collaboration-tool tests passed. - Structured parent-to-child `input_text` delivery tests passed. - Fail-closed tests for encrypted delivery to a third-party child passed. - Release build succeeded. - After fully restarting Codex Desktop with the local build, an OpenAI parent successfully spawned a third-party-provider child. - The child received the assignment, executed it, and returned the expected fixed marker. - The default encrypted behavior remains unchanged. ## Expected upstream behavior A complete upstream solution should: 1. Keep encrypted delivery as the default. 2. Provide an explicit plaintext delivery policy for providers that cannot consume OpenAI encrypted tool parameters. 3. Apply the policy consistently across tool schemas, planning, routing, and message construction. 4. Support a non-reserved tool namespace for plaintext collaboration schemas. 5. Fail before spawning when encrypted delivery is incompatible with the selected child provider. 6. Add an end-to-end integration test for an OpenAI parent spawning a third-party-provider child.", "url": "https://github.com/openai/codex/issues/37197", "createdAt": "2026-08-06T02:23:00Z", "updatedAt": "2026-08-13T14:21:20Z", "timestamp": "2026-08-13T14:21:20Z", "metrics": { "reactions": 0, "comments": 2 }, "labels": [ "bug", "windows-os", "custom-model", "app", "subagent" ], "author": "YukiagoTpf", "state": "open", "assignees": [] }, { "id": "github:openai/codex:issue:37237", "source": "github", "group": "coding-agent-infrastructure", "project": "openai/codex", "kind": "issue", "title": "`spawn_agent` silently creates empty sub-agents for any non-OpenAI Responses provider — task body sent as `encrypted_content` and dropped, with zero diagnostics", "text": "### Summary The ChatGPT desktop app's embedded Codex runtime (cli `0.147.0-alpha.1.2`, app `26.730.61639`) creates sub-agents via `spawn_agent` / `followup_task`, but when `model_provider` points at a non-OpenAI Responses-compatible endpoint (`wire_api=\"responses\"` -> e.g. `https://api.deepseek.com`), **the task body never reaches the sub-agent**. The sub-agent spawns, sees only an empty \"Message Type: NEW_TASK ... Payload:\" header, and replies *\"I don't see a specific task.\"* Switching `model_provider` to the OpenAI backend makes it work. No error is surfaced anywhere. This silently breaks the multi-agent feature for every third-party provider. ### Repro `config.toml`: ```toml model = \"deepseek-v4-flash\" model_provider = \"deepseek\" [model_providers.deepseek] name = \"DeepSeek\" base_url = \"https://api.deepseek.com\" wire_api = \"responses\" ``` In a session: 1. `spawn_agent(task_name=\"test\", message=\"Reply with DELIVERY_OK only\", fork_turns=\"none\")` 2. `wait_agent` 3. `list_agents` Observed: `spawn_agent` returns `{\"task_name\": \"/root/test\"}` (success). But `list_agents` shows the sub-agent completed with *\"Hi! It looks like your message may not have come through yet — I don't see a specific request to work on.\"* ### Root cause — captured from the wire The HTTP request the app sends to the third-party endpoint serializes the task as: ```json {\"type\":\"agent_message\",\"author\":\"/root\",\"recipient\":\"/root/test\",\"content\":[ {\"type\":\"input_text\",\"text\":\"Message Type: NEW_TASK\\nTask name: /root/test\\nSender: /root\\nPayload:\\n\"}, {\"type\":\"encrypted_content\",\"encrypted_content\":\"Reply with DELIVERY_OK only\"} ]} ``` The `encrypted_content` content item is forwarded verbatim. A third-party Responses endpoint has no way to render that type, so the body is dropped and the model only sees the empty `Payload:` header. The same spawn under `model_provider=\"openai\"` resolves correctly. Notes: - This is **not** a tool-contract problem: `spawn_agent`'s `task_name` / `message` / `fork_turns` arguments are exactly as documented, and the handler returns a valid task path. - `followup_task` (`target` + `message`) fails the same way; its output is silently empty. - `fork_turns=\"all\"` partially masks it: the child gets the parent's forked history, but still not the per-agent spawn message. `fork_turns=\"none\"` yields a fully empty agent. Suspected area: the multi-agent v2 delivery path (`core/src/tools/handlers/multi_agents_v2/spawn_agent.rs`, `followup_task.rs`) and `core/src/agent_communication.rs`, where inter-agent messages are stored/transported as `encrypted_content` items and only expanded on the OpenAI backend. ### Expected behavior - `encrypted_content` in agent-message payloads must be decrypted/expanded to plaintext `input_text` **before** the request is serialized to any provider; **or** - if that expansion is intentionally OpenAI-only, `spawn_agent` / `followup_task` must fail loudly with a clear error instead of silently spawning an empty agent. Silently creating a sub-agent with no task — and silently returning empty results for `followup_task` / `send_message` — is the worst possible failure mode: no exception, no log, just empty agents doing nothing. ### Environment - macOS (Darwin 25.5.0) - ChatGPT desktop app `26.730.61639` (build 6234), embedded Codex runtime `cli 0.147.0-alpha.1.2` - `model=deepseek-v4-flash`, `model_provider=deepseek`, `base_url=https://api.deepseek.com`, `wire_api=responses`", "url": "https://github.com/openai/codex/issues/37237", "createdAt": "2026-08-06T08:43:54Z", "updatedAt": "2026-08-13T02:59:25Z", "timestamp": "2026-08-13T02:59:25Z", "metrics": { "reactions": 0, "comments": 3 }, "labels": [ "bug", "custom-model", "app", "subagent" ], "author": "ShepherdPrometheus", "state": "open", "assignees": [] }, { "id": "github:openai/codex:issue:37272", "source": "github", "group": "coding-agent-infrastructure", "project": "openai/codex", "kind": "issue", "title": "[Windows] Computer Use fails with `spawn EPERM` after Codex update", "text": "### Summary Computer Use worked on Codex app version 26.727.6591.0, but after the Microsoft Store updated the app to 26.730.8199.0, every Computer Use action fails immediately with `spawn EPERM`, before windows can be enumerated or any application can be controlled. The failure reproduces both in an existing task and in a newly created Work task. ### Environment - Windows 10 Enterprise 22H2 (build 19045.6456) - Codex app: 26.730.8199.0 - Computer Use plugin/runtime: 26.730.61639 - Same result when Codex is started normally or elevated ### Steps to reproduce 1. Install and enable the Computer Use plugin and skill. 2. Click **Try now** or create a new Work task. 3. Ask Computer Use to inspect the visible desktop/RDP window or launch an allowed Windows application. 4. The first controller action fails immediately. Examples that fail: - `sky.list_windows()` - `sky.launch_app({ app: \"winword.exe\" })` ### Actual behavior The local Computer Use controller returns `spawn EPERM` before listing windows. No mouse, keyboard, application, or RDP interaction occurs. ### Expected behavior Computer Use should enumerate visible windows and control an allowed Windows application, as it did before the app update. ### Troubleshooting already performed - Repaired the Codex app through Windows Settings. - Uninstalled and reinstalled the Computer Use plugin. - Restarted Codex and reproduced in a new task. - Regenerated the bundled `cua_node` runtime from scratch. - Verified that the bundled controller executable exists and has Read/Execute permission. - Verified that the native controller pipe is created. - Tested both normal and elevated Codex processes. - Checked Microsoft Defender, AppLocker, and Code Integrity logs; no corresponding block or quarantine event was found. The issue began immediately after the automatic Codex update, so this appears to be a regression or a version mismatch between Codex 26.730.8199.0 and the Computer Use runtime 26.730.61639.", "url": "https://github.com/openai/codex/issues/37272", "createdAt": "2026-08-06T13:36:17Z", "updatedAt": "2026-08-12T18:10:52Z", "timestamp": "2026-08-12T18:10:52Z", "metrics": { "reactions": 0, "comments": 3 }, "labels": [ "bug", "windows-os", "app", "computer-use" ], "author": "gutogral-tech", "state": "open", "assignees": [] }, { "id": "github:openai/codex:issue:37299", "source": "github", "group": "coding-agent-infrastructure", "project": "openai/codex", "kind": "issue", "title": "Desktop wait/status orchestration re-meters full cached context every 10-30s; stale 'running' subagents keep it looping (90% of weekly Pro in 15.5h)", "text": "## Summary Long-running Codex Desktop tasks that orchestrate subagents and background commands consume extreme weekly usage while effectively idle. The driver is that every small wait/status result triggers a model turn that re-meters the task's entire accumulated context (~140k tokens at 97–98% cached in our case), and Desktop's orchestration issues these waits on 10–30s timeouts against work that takes minutes to hours. A newly activated Pro account went from 0% to 90% of its weekly limit in ~15.5 hours this way; the account usage API reported ~290M tokens for that single day (Aug 5). Related: #4764 (large cached contexts consuming limits). This report adds the Desktop wait/status orchestration angle plus a subagent lifecycle defect that keeps the pattern running. ## Environment - Codex Desktop (app-server `0.147.0-alpha.1.2`), macOS 15 (Darwin 24.6.0) - Model `gpt-5.6-sol`, reasoning `xhigh`/`max`, multi-agent + code-mode enabled ## Measurements (local session rollouts, fork/replay events deduplicated) Over Aug 4–6: - **75% of all model-visible tool calls were `wait` / `wait_agent` / `list_agents`** (8,744 of 11,002). Observed timeout arguments: `wait` mostly `yield_time_ms` 10,000–30,000; `wait_agent` mostly `timeout_ms` 30,000–60,000. - **83% of `wait_agent` calls returned `timed_out: true`** (1,765 of 2,122) — no-op turns whose only effect is re-metering the full cached context. - Average input per turn ~137–141k tokens, 97.4–98.1% cached, sustained across 15–25k turns/day (2.4–3.6B input tokens/day processed on one workstation). - One long-lived thread issued 3,834 wait-family calls over its lifetime. - Tool outputs returned through `wait` totaled 28.2MB over three days (60% of all tool-result bytes), much of it unprojected upstream API JSON that then persists in context and is re-metered on every subsequent turn. ## Subagent lifecycle defect (keeps the loop alive and inflates rosters) - Completed subagents remain `running`/\"Working\" in the roster and UI for days. In our local Codex state, **1,154 child-task relationships are marked open; 1,071 have no update for >24h; 815 for >72h; in a 200-item sample, 184 already contained a final answer.** - Direct example: a subagent whose rollout file went silent at 06:42 still reported `agent_status: \"running\"` in `list_agents` at 07:48. - Thread forks/continuations rewrite the full rollout history in bulk (e.g., an 86MB rollout written in under a minute, 8,879 of 8,908 token events being replayed history) and re-import the parent roster including stale \"running\" agents — so ghost agents survive across generations, and parents keep polling agents that will never change state. - `list_agents` embeds each completed agent's **entire final message** in the roster payload, so every roster check re-injects those reports into context. ## Impact - Fresh Pro weekly limit 0% → 90% in ~15.5 hours, dominated by two long-lived tasks; ~290M account-reported tokens in one day. - The workload pattern (agentic delivery with verifier subagents and CI waits) is exactly what Desktop multi-agent encourages, so this scales with adoption of the feature. ## Suggested directions 1. Server-side or client-side long-wait primitive: a bounded wait on subagents/commands should not cost one full-context model turn per 10–30s slice, and a `timed_out` no-change result ideally should not trigger a model turn at all. 2. Fix child-task lifecycle: transition completed subagents out of `running` without requiring the parent to reap them; do not re-import stale rosters into forks/continuations. 3. Return roster/status summaries (name, state, timestamps) instead of embedding full final messages in `list_agents`. 4. Clarify how cached context in orchestration turns is weighted against plan limits (follow-up to #4764) — the current behavior makes long-lived tasks pay near-max context for idle polling. Happy to provide session IDs, rollout excerpts, timestamps, and the affected account privately through support (ticket references this issue). cc @tibo-openai", "url": "https://github.com/openai/codex/issues/37299", "createdAt": "2026-08-06T15:43:41Z", "updatedAt": "2026-08-13T01:23:02Z", "timestamp": "2026-08-13T01:23:02Z", "metrics": { "reactions": 0, "comments": 1 }, "labels": [], "author": "swordfish444", "state": "open", "assignees": [] }, { "id": "github:openai/codex:issue:37300", "source": "github", "group": "coding-agent-infrastructure", "project": "openai/codex", "kind": "issue", "title": "failed to handle OAuth callback (cloudfare-api)", "text": "Command: codex mcp login cloudflare-api MCP URL: https://mcp.cloudflare.com/mcp Error: failed to handle OAuth callback Authorization server response missing required issuer: expected https://mcp.cloudflare.com codex-cli 0.146.1", "url": "https://github.com/openai/codex/issues/37300", "createdAt": "2026-08-06T15:50:28Z", "updatedAt": "2026-08-12T22:49:00Z", "timestamp": "2026-08-12T22:49:00Z", "metrics": { "reactions": 0, "comments": 1 }, "labels": [], "author": "torahmike", "state": "open", "assignees": [] }, { "id": "github:openai/codex:issue:37301", "source": "github", "group": "coding-agent-infrastructure", "project": "openai/codex", "kind": "issue", "title": "Session repeatedly \"waiting for agents\" although all subagents are stopped", "text": "### What version of Codex CLI is running? v0.146.1 ### What subscription do you have? Pro ### Which model were you using? gpt-5.6-sol high ### What platform is your computer? Linux 7.0.0-28-generic x86_64 x86_64 ### What terminal emulator and version are you using (if applicable)? _No response_ ### Codex doctor report ```json { \"schemaVersion\": 1, \"generatedAt\": \"1786032186s since unix epoch\", \"overallStatus\": \"ok\", \"codexVersion\": \"0.146.1\", \"checks\": { \"app_server.status\": { \"id\": \"app_server.status\", \"category\": \"app-server\", \"status\": \"ok\", \"summary\": \"background server is not running\", \"details\": { \"control socket\": \"/home/trippy/.codex/app-server-control/app-server-control.sock\", \"daemon state dir\": \"/home/trippy/.codex/app-server-daemon\", \"mode\": \"ephemeral\", \"pid file\": \"/home/trippy/.codex/app-server-daemon/app-server.pid (missing)\", \"settings\": \"/home/trippy/.codex/app-server-daemon/settings.json (missing)\", \"status\": \"not running\", \"update-loop pid file\": \"/home/trippy/.codex/app-server-daemon/app-server-updater.pid (missing)\" }, \"remediation\": null, \"durationMs\": 0 }, \"auth.credentials\": { \"id\": \"auth.credentials\", \"category\": \"auth\", \"status\": \"ok\", \"summary\": \"auth is configured\", \"details\": { \"auth file\": \"/home/trippy/.codex/auth.json\", \"auth storage mode\": \"File\", \"stored API key\": \"false\", \"stored ChatGPT tokens\": \"true\", \"stored agent identity\": \"false\", \"stored auth mode\": \"chatgpt\" }, \"remediation\": null, \"durationMs\": 0 }, \"config.load\": { \"id\": \"config.load\", \"category\": \"config\", \"status\": \"ok\", \"summary\": \"config loaded\", \"details\": { \"CODEX_HOME\": \"/home/trippy/.codex\", \"config.toml\": \"/home/trippy/.codex/config.toml\", \"config.toml parse\": \"ok\", \"cwd\": \"/home/trippy/uncertaintea/db\", \"enabled feature flags\": \"shell_tool, unified_exec, shell_snapshot, code_mode_host, terminal_resize_reflow, sqlite, hooks, enable_request_compression, multi_agent, apps, tool_search_always_defer_mcp_tools, tool_suggest, plugins, in_app_browser, in_app_updates, browser_use, browser_use_full_cdp_access, browser_use_external, computer_use, remote_plugin, plugin_sharing, image_generation, resize_all_images, item_ids, skill_mcp_dependency_install, skill_search, mentions_v2, steer, guardian_approval, goals, collaboration_modes, tool_call_mcp_elicitation, auth_elicitation, personality, fast_mode, tui_app_server, remote_compaction_v2, workspace_dependencies\", \"feature flag overrides\": \"none\", \"feature flags enabled\": \"38\", \"log dir\": \"/home/trippy/.codex/log\", \"mcp servers\": \"1\", \"model\": \"gpt-5.6-sol\", \"model provider\": \"openai\", \"sqlite home\": \"/home/trippy/.codex\" }, \"remediation\": null, \"durationMs\": 0 }, \"git.environment\": { \"id\": \"git.environment\", \"category\": \"git\", \"status\": \"ok\", \"summary\": \"git version 2.43.0\", \"details\": { \".git entry\": \"directory\", \"PATH git #1\": \"/usr/bin/git\", \"PATH git #2\": \"/bin/git\", \"PATH git entries\": \"2\", \"git branch\": \"main\", \"git build options\": \"git version 2.43.0; cpu: x86_64; no commit associated with this build; sizeof-long: 8; sizeof-size_t: 8; shell-path: /bin/sh\", \"git exec path\": \"/usr/lib/git-core\", \"git version\": \"git version 2.43.0\", \"repo detected\": \"true\", \"repo root\": \"/home/trippy/uncertaintea/db\", \"selected git\": \"/usr/bin/git\" }, \"remediation\": null, \"durationMs\": 29 }, \"installation\": { \"id\": \"installation\", \"category\": \"install\", \"status\": \"ok\", \"summary\": \"installation looks consistent\", \"details\": { \"PATH codex #1\": \"/home/trippy/.nvm/versions/node/v24.16.0/bin/codex\", \"current executable\": \"/home/trippy/.nvm/versions/node/v24.16.0/lib/node_modules/@openai/codex/node_modules/@openai/codex-linux-x64/vendor/x86_64-unknown-linux-musl/bin/codex\", \"install context\": \"npm (package /home/trippy/.nvm/versions/node/v24.16.0/lib/node_modules/@openai/codex/node_modules/@openai/codex-linux-x64/vendor/x86_64-unknown-linux-musl, bin /home/trippy/.nvm/versions/node/v24.16.0/lib/node_modules/@openai/codex/node_modules/@openai/codex-linux-x64/vendor/x86_64-unknown-linux-musl/bin, resources /home/trippy/.nvm/versions/node/v24.16.0/lib/node_modules/@openai/codex/node_modules/@openai/codex-linux-x64/vendor/x86_64-unknown-linux-musl/codex-resources, path /home/trippy/.nvm/versions/node/v24.16.0/lib/node_modules/@openai/codex/node_modules/@openai/codex-linux-x64/vendor/x86_64-unknown-linux-musl/codex-path)\", \"managed by bun\": \"false\", \"managed by npm\": \"true\", \"managed by pnpm\": \"false\", \"managed package root\": \"/home/trippy/.nvm/versions/node/v24.16.0/lib/node_modules/@openai/codex\", \"npm update target\": \"/home/trippy/.nvm/versions/node/v24.16.0/lib/node_modules/@openai/codex\" }, \"remediation\": null, \"durationMs\": 61 }, \"mcp.config\": { \"id\": \"mcp.config\", \"category\": \"mcp\", \"status\": \"ok\", \"summary\": \"MCP configuration is locally consistent\", \"details\": { \"configured servers\": \"1\", \"disabled servers\": \"0\", \"stdio servers\": \"1\" }, \"remediation\": null, \"durationMs\": 0 }, \"network.env\": { \"id\": \"network.env\", \"category\": \"network\", \"status\": \"ok\", \"summary\": \"network-related environment looks readable\", \"details\": { \"proxy env vars\": \"none\" }, \"remediation\": null, \"durationMs\": 0 }, \"network.provider_reachability\": { \"id\": \"network.provider_reachability\", \"category\": \"reachability\", \"status\": \"ok\", \"summary\": \"active provider endpoints are reachable over HTTP\", \"details\": { \"ChatGPT base URL\": \"https://chatgpt.com/backend-api/ reachable (HTTP 404)\", \"reachability mode\": \"ChatGPT auth\" }, \"remediation\": null, \"durationMs\": 147 }, \"network.websocket_reachability\": { \"id\": \"network.websocket_reachability\", \"category\": \"websocket\", \"status\": \"ok\", \"summary\": \"Responses WebSocket handshake succeeded\", \"details\": { \"DNS\": \"2 IPv4, 2 IPv6, first IPv4\", \"auth mode\": \"chatgpt\", \"connect timeout\": \"15000 ms\", \"endpoint\": \"wss://chatgpt.com/backend-api/\", \"handshake result\": \"HTTP 101 Switching Protocols\", \"model provider\": \"openai\", \"models etag present\": \"true\", \"provider name\": \"OpenAI\", \"proxy env vars\": \"none\", \"reasoning header\": \"false\", \"server model present\": \"false\", \"supports websockets\": \"true\", \"wire API\": \"responses\" }, \"remediation\": null, \"durationMs\": 625 }, \"runtime.provenance\": { \"id\": \"runtime.provenance\", \"category\": \"runtime\", \"status\": \"ok\", \"summary\": \"running npm on linux-x86_64\", \"details\": { \"commit\": \"unknown\", \"current executable\": \"/home/trippy/.nvm/versions/node/v24.16.0/lib/node_modules/@openai/codex/node_modules/@openai/codex-linux-x64/vendor/x86_64-unknown-linux-musl/bin/codex\", \"install method\": \"npm (package /home/trippy/.nvm/versions/node/v24.16.0/lib/node_modules/@openai/codex/node_modules/@openai/codex-linux-x64/vendor/x86_64-unknown-linux-musl, bin /home/trippy/.nvm/versions/node/v24.16.0/lib/node_modules/@openai/codex/node_modules/@openai/codex-linux-x64/vendor/x86_64-unknown-linux-musl/bin, resources /home/trippy/.nvm/versions/node/v24.16.0/lib/node_modules/@openai/codex/node_modules/@openai/codex-linux-x64/vendor/x86_64-unknown-linux-musl/codex-resources, path /home/trippy/.nvm/versions/node/v24.16.0/lib/node_modules/@openai/codex/node_modules/@openai/codex-linux-x64/vendor/x86_64-unknown-linux-musl/codex-path)\", \"platform\": \"linux-x86_64\", \"version\": \"0.146.1\" }, \"remediation\": null, \"durationMs\": 0 }, \"runtime.search\": { \"id\": \"runtime.search\", \"category\": \"search\", \"status\": \"ok\", \"summary\": \"search is OK (bundled)\", \"details\": { \"search command\": \"/home/trippy/.nvm/versions/node/v24.16.0/lib/node_modules/@openai/codex/node_modules/@openai/codex-linux-x64/vendor/x86_64-unknown-linux-musl/codex-path/rg\", \"search command readiness\": \"file exists\", \"search provider\": \"bundled\" }, \"remediation\": null, \"durationMs\": 0 }, \"sandbox.helpers\": { \"id\": \"sandbox.helpers\", \"category\": \"sandbox\", \"status\": \"ok\", \"summary\": \"sandbox configuration is readable\", \"details\": { \"approval policy\": \"OnRequest\", \"codex-linux-sandbox helper\": \"/home/trippy/.codex/tmp/arg0/codex-arg00pquda/codex-linux-sandbox\", \"execve wrapper helper\": \"/home/trippy/.codex/tmp/arg0/codex-arg00pquda/codex-execve-wrapper\", \"filesystem sandbox\": \"restricted\", \"network sandbox\": \"restricted\" }, \"remediation\": null, \"durationMs\": 0 }, \"state.paths\": { \"id\": \"state.paths\", \"category\": \"state\", \"status\": \"ok\", \"summary\": \"state paths and databases are inspectable\", \"details\": { \"CODEX_HOME\": \"/home/trippy/.codex (dir)\", \"active rollout files\": \"331 files, 175409955 total bytes, 529939 average bytes\", \"archived rollout files\": \"0 files, 0 total bytes, 0 average bytes\", \"goals DB\": \"/home/trippy/.codex/goals_1.sqlite (file)\", \"goals DB integrity\": \"ok\", \"log DB\": \"/home/trippy/.codex/logs_2.sqlite (file)\", \"log DB integrity\": \"ok\", \"log dir\": \"/home/trippy/.codex/log (dir)\", \"memories DB\": \"/home/trippy/.codex/memories_1.sqlite (file)\", \"memories DB integrity\": \"ok\", \"sqlite home\": \"/home/trippy/.codex (dir)\", \"state DB\": \"/home/trippy/.codex/state_5.sqlite (file)\", \"state DB integrity\": \"ok\", \"thread history DB\": \"/home/trippy/.codex/thread_history_1.sqlite (missing)\", \"thread history DB integrity\": \"skipped (missing)\" }, \"remediation\": null, \"durationMs\": 1262 }, \"state.rollout_db_parity\": { \"id\": \"state.rollout_db_parity\", \"category\": \"threads\", \"status\": \"ok\", \"summary\": \"rollout files and state DB thread inventory agree\", \"details\": { \"default model provider\": \"openai\", \"rollout DB active files\": \"331\", \"rollout DB active rows\": \"331\", \"rollout DB archive mismatches\": \"0\", \"rollout DB archived files\": \"0\", \"rollout DB archived rows\": \"0\", \"rollout DB duplicate DB paths\": \"0\", \"rollout DB duplicate rollout thread ids\": \"0\", \"rollout DB malformed file names\": \"0\", \"rollout DB missing active rows\": \"0\", \"rollout DB missing archived rows\": \"0\", \"rollout DB model providers\": \"openai=331\", \"rollout DB rows\": \"331\", \"rollout DB scan cap reached\": \"false\", \"rollout DB scan errors\": \"0\", \"rollout DB sources\": \"cli=268, subagent:review=44, vscode=13, subagent:thread_spawn=6\", \"rollout DB stale rows\": \"0\" }, \"remediation\": null, \"durationMs\": 100 }, \"system.environment\": { \"id\": \"system.environment\", \"category\": \"system\", \"status\": \"ok\", \"summary\": \"OS language en-US\", \"details\": { \"EDITOR\": \"set\", \"LANG\": \"en_US.UTF-8\", \"VISUAL\": \"set\", \"os\": \"Ubuntu 24.4.0 (noble) [64-bit]\", \"os language\": \"en-US\", \"os type\": \"Ubuntu\", \"os version\": \"24.4.0\" }, \"remediation\": null, \"durationMs\": 4 }, \"terminal.env\": { \"id\": \"terminal.env\", \"category\": \"terminal\", \"status\": \"ok\", \"summary\": \"terminal metadata was detected\", \"details\": { \"COLORTERM\": \"truecolor\", \"DISPLAY\": \"present\", \"color output\": \"enabled\", \"effective locale\": \"en_US.UTF-8\", \"stderr is terminal\": \"true\", \"stdin is terminal\": \"true\", \"stdout is terminal\": \"true\", \"terminal\": \"GNOME Terminal\", \"terminal size\": \"94x48\" }, \"remediation\": null, \"durationMs\": 0 }, \"terminal.title\": { \"id\": \"terminal.title\", \"category\": \"title\", \"status\": \"ok\", \"summary\": \"terminal title default\", \"details\": { \"terminal title activity\": \"true\", \"terminal title items\": \"activity, project-name\", \"terminal title project source\": \"git repo root\", \"terminal title project value\": \"db\", \"terminal title source\": \"default\" }, \"remediation\": null, \"durationMs\": 0 }, \"updates.status\": { \"id\": \"updates.status\", \"category\": \"updates\", \"status\": \"ok\", \"summary\": \"update configuration is locally consistent\", \"details\": { \"cached latest version\": \"0.146.1\", \"check for update on startup\": \"true\", \"last checked at\": \"2026-08-06T01:10:14.348631517Z\", \"latest version\": \"0.146.1\", \"latest version status\": \"current version is not older\", \"npm update target\": \"/home/trippy/.nvm/versions/node/v24.16.0/lib/node_modules/@openai/codex\", \"update action\": \"npm install -g @openai/codex\", \"version cache\": \"/home/trippy/.codex/version.json\" }, \"remediation\": null, \"durationMs\": 266 } } } ``` ### What issue are you seeing? I was running a session with three subagents. Two subagents were finished with their work, but one was interrupted because I hit on a permission prompt to tell it to do something else. I don't know if my follow-up instructions ever made it to the subagent. The main session kept repeatedly saying \"Waiting for agents\" in a loop, even though all agents were idle. I verified that they were idle by cycling through the output using -Next. ### What steps can reproduce the bug? Uploaded thread: 019fd49f-7db8-7b71-85ac-d74bfff03f51 ### What is the expected behavior? I would have expected that the main session would notice that the subagents were finished or interrupted, and either: - Say that the work was complete, or: - Highlight that one of the agents was blocked and ask for further instructions. Either way, it shouldn't keep running, possibly burning tokens. ### Additional information _No response_", "url": "https://github.com/openai/codex/issues/37301", "createdAt": "2026-08-06T16:10:49Z", "updatedAt": "2026-08-13T10:53:41Z", "timestamp": "2026-08-13T10:53:41Z", "metrics": { "reactions": 2, "comments": 2 }, "labels": [ "bug", "CLI", "subagent" ], "author": "TonyRippy", "state": "open", "assignees": [] }, { "id": "github:openai/codex:issue:37373", "source": "github", "group": "coding-agent-infrastructure", "project": "openai/codex", "kind": "issue", "title": "MCP app-server 0.147 strips trailing slash from expected authorization-server issuer", "text": "### What version of Codex is running? `codex-cli 0.147.0-alpha.6.5`, bundled with ChatGPT Desktop `26.803.41515` (build `6321`). ### Platform macOS arm64. ### What issue are you seeing? The 0.147 app-server rejects an already-authenticated Streamable HTTP MCP server while initializing/calling its tools because the expected authorization-server issuer has had its trailing slash removed, but the issuer returned by authorization-server metadata retains that slash. Sanitized form of the error: ```text issuer mismatch: expected https://auth.example.invalid/oauth2 received https://auth.example.invalid/oauth2/ ``` The MCP URL-only configuration has no static bearer token or headers. `mcpServerStatus/list` reports `authStatus=oAuth` but exposes an empty tool catalog; a direct read-only `mcpServer/tool/call` then returns the issuer mismatch. ### Reproduction 1. Configure a Streamable HTTP MCP server using only a URL such as `https://mcp.example.invalid/mcp`. 2. Complete OAuth once. The authorization-server metadata advertises an issuer ending in `/`, such as `https://auth.example.invalid/oauth2/`. 3. Start the bundled 0.147 app-server over stdio. 4. Send `initialize` with `experimentalApi=true`, then `initialized`. 5. Start an ephemeral read-only thread. 6. Call `mcpServerStatus/list`, followed by a read-only `mcpServer/tool/call`. ### Control evidence On the same machine, against the same unchanged MCP endpoint and stored OAuth account: - pinned `@openai/codex@0.146.1` app-server succeeds; - its allowlisted read-only catalog contains exactly three tools; - a fresh serial traversal completed 42/42 tool calls (3 metadata and 39 tree calls) with zero OAuth or issuer errors; - bundled `0.147.0-alpha.6.5` fails before the first tool result with the mismatch above. No PAT, copied bearer token, custom OAuth client secret, browser scraping, or direct REST fallback is involved. ### Expected behavior Codex should preserve and compare the same canonical issuer value on both sides. If authorization-server metadata declares `https://auth.example.invalid/oauth2/`, the client must not strip the slash only from its expected value and then reject the metadata value it originally discovered. ### Relationship to existing issues This appears distinct from: - #31573, where the OAuth callback handler drops the RFC 9207 `iss` parameter; - #35716, where an OAuth `resource` parameter gains a trailing slash. This failure happens when an already-authenticated MCP server is initialized/called through app-server, and concerns authorization-server issuer canonicalization rather than callback parsing or the protected-resource parameter.", "url": "https://github.com/openai/codex/issues/37373", "createdAt": "2026-08-07T03:59:40Z", "updatedAt": "2026-08-13T17:07:04Z", "timestamp": "2026-08-13T17:07:04Z", "metrics": { "reactions": 3, "comments": 5 }, "labels": [ "bug", "auth", "mcp", "app", "app-server" ], "author": "Charpup", "state": "open", "assignees": [] }, { "id": "github:openai/codex:issue:37398", "source": "github", "group": "coding-agent-infrastructure", "project": "openai/codex", "kind": "issue", "title": "Codex Desktop: opening any unloaded local chat waits ~5 seconds on owner discovery timeout", "text": "## Summary Codex Desktop waits about five seconds before displaying any unloaded local chat, even when the chat transcript is small. The actual thread read/resume completes in under 200 ms; the delay is a fixed owner-discovery timeout before fallback. ## Environment - ChatGPT/Codex Desktop: **26.803.41515** (build **6321**) - Bundled Codex: **0.147.0-alpha.6.5** - macOS **26.5.1**, arm64 ## Steps to reproduce 1. Launch the desktop app. 2. Open any unloaded local chat. 3. Observe that the content appears only after about five seconds. This reproduces with a small local transcript of 3,075,688 bytes, so it is not limited to large chats. ## Expected behavior The chat should appear as soon as `thread/read` and `thread/resume` complete. ## Actual behavior and timing Sanitized diagnostic timing from one reproduction: - `maybe_resume_started`: `2026-08-07T07:00:43.245Z` - `maybe_resume_owner_discovery_failed` with `timeout`: `2026-08-07T07:00:48.252Z` - Fixed wait before fallback: approximately **5,007 ms** - `thread/read` after fallback: **3 ms** - `thread/resume` after fallback: **182 ms** A background `avatarOverlay` renderer also emits `Conversation state not found`, although Pets were never enabled or opened by the user. The same owner-discovery timeout reproduces across multiple local threads. Deleting large chats and fully restarting the app did not eliminate the fixed delay. ## Privacy No raw logs, session transcript, browser tabs, or conversation content are attached.", "url": "https://github.com/openai/codex/issues/37398", "createdAt": "2026-08-07T07:23:11Z", "updatedAt": "2026-08-13T13:26:34Z", "timestamp": "2026-08-13T13:26:34Z", "metrics": { "reactions": 9, "comments": 15 }, "labels": [ "bug", "app", "session", "performance" ], "author": "galaxychi", "state": "open", "assignees": [] }, { "id": "github:openai/codex:issue:37403", "source": "github", "group": "coding-agent-infrastructure", "project": "openai/codex", "kind": "issue", "title": "[macOS][regression] Desktop cannot resume Remote Control / CLI thread: `already has an active writer` after latest update", "text": "## Summary After updating the ChatGPT Desktop client on macOS on **August 7, 2026**, an existing workflow that previously worked stopped working: - During off-hours, I use **ChatGPT mobile Remote Control** to continue a Codex CLI thread on my Mac. - During the day, I open the same thread in the **Desktop client** and continue from there. After the latest Desktop update, the Desktop/CLI handoff fails because the thread is reported as already having an active writer. This appears to be a regression in thread ownership / writer handoff between the Desktop-bundled app-server/runtime and the CLI/Remote Control runtime. ## Environment - Platform: macOS (iMac) - Standalone CLI: ```text codex-cli 0.147.0 ``` - ChatGPT Desktop bundled Codex runtime: ```text /Applications/ChatGPT.app/Contents/Resources/codex --version codex-cli 0.147.0-alpha.6.5 ``` - The issue started immediately after installing the latest ChatGPT Desktop update on August 7, 2026. - The same Remote Control / CLI / Desktop workflow worked before that update. ## Steps to reproduce 1. Keep Codex Remote Control enabled on the Mac. 2. Use ChatGPT mobile Remote Control to open/continue a Codex CLI thread. 3. Later, on the same Mac, try to resume/open that same thread from the Desktop client. 4. Observe that the thread cannot be resumed because another writer is considered active. ## Actual behavior The resume attempt fails with an error like: ```text Failed to resume session from ~/.codex/sessions/YYYY/MM/DD/rollout-...jsonl: thread/resume failed during TUI bootstrap: thread/resume failed: thread already has an active writer (code -32600) ``` A key observation: - With the Desktop client running, the thread hits the `already has an active writer` conflict. - If I **fully quit the Desktop client**, the same session can immediately be opened/resumed normally from the standalone CLI. The session JSONL itself therefore appears intact; the problem looks like writer ownership/lifecycle rather than session corruption. ## Expected behavior Remote Control is intended to let the same work continue across mobile and desktop usage. A thread used through Remote Control / CLI should be able to hand off cleanly to Desktop when the user returns to the Mac. Expected flow: ```text Mobile Remote Control / CLI thread ↓ user stops actively using mobile ↓ Desktop resumes the same thread ↓ ownership/writer handoff succeeds ``` The user should not need to disable Remote Control, kill app-server processes, fork the conversation, or create a new thread just to switch between mobile and Desktop. ## Impact This breaks a core daily workflow: - Desktop during work hours - Mobile Remote Control after work - Same Codex thread/context across both surfaces Because Remote Control needs to remain enabled, simply turning it off is not a practical workaround. ## Regression evidence The behavior changed immediately after the latest Desktop update. No CLI configuration or session files were changed at the time. The standalone CLI and Desktop-bundled runtime are different builds: ```text Standalone: 0.147.0 Desktop bundled: 0.147.0-alpha.6.5 ``` This may be related to stricter single-writer enforcement without a corresponding Desktop ↔ Remote Control ownership handoff. ## Privacy note The local username, exact session path, thread ID, repository/project names, and conversation contents are intentionally omitted. I can provide additional sanitized diagnostics if maintainers request them.", "url": "https://github.com/openai/codex/issues/37403", "createdAt": "2026-08-07T08:14:10Z", "updatedAt": "2026-08-13T09:54:31Z", "timestamp": "2026-08-13T09:54:31Z", "metrics": { "reactions": 10, "comments": 17 }, "labels": [ "bug", "app", "app-server", "remote" ], "author": "xkun1", "state": "open", "assignees": [] }, { "id": "github:openai/codex:issue:37415", "source": "github", "group": "coding-agent-infrastructure", "project": "openai/codex", "kind": "issue", "title": "Windows Computer Use fails with spawn EPERM; elevated sandbox setup fails on WindowsApps ACL", "text": "### What version of the Codex App are you using (From “About Codex” dialog)? OpenAI.Codex 26.803.5235.0 (Computer Use plugin 26.803.41515; bundled Codex CLI 0.147.0-alpha.6.5; @oai/sky 0.6.2) ### What subscription do you have? Unknown / not displayed in the Codex App ### What platform is your computer? Windows 11 Pro 25H2, build 26200.8973, x64; Codex installed as AppX/MSIX ### What issue are you seeing? The bundled Computer Use plugin cannot perform its first read-only operation on Windows. Importing `@oai/sky` succeeds, but `await sky.list_windows()` fails immediately with: ```text Error: spawn EPERM at ChildProcess.spawn (node:internal/child_process:421:11) at spawn (node:child_process:796:9) at ...\\@oai\\sky\\...\\windows\\internal\\helper_transport.js ``` The helper path (PII redacted) is: `C:\\Users\\\\AppData\\Local\\OpenAI\\Codex\\runtimes\\cua_node\\f1bf3cd3a5929acd\\bin\\node_modules\\@oai\\sky\\bin\\windows\\codex-computer-use.exe` Every Computer Use operation fails before connecting to the signed bundled helper because sandboxed Node child-process creation returns `EPERM`. Updating system Node.js does not affect this because Computer Use uses its bundled runtime. ### What steps can reproduce the bug? 1. Install/enable `computer-use@openai-bundled` in the Windows Codex desktop app. 2. Start a fresh task. 3. Initialize the documented runtime: ```js if (!globalThis.sky) { const { sky } = await import(\"@oai/sky\"); globalThis.sky = sky; } ``` 4. Run the first read-only operation: ```js await sky.list_windows(); ``` 5. Observe `Error: spawn EPERM`. Reproduces after a full Windows restart, clean app reinstall, Computer Use plugin/runtime refresh, and Node kernel reset. ### What is the expected behavior? `sky.list_windows()` should launch or connect to the bundled signed helper and return the available Windows application windows. Computer Use should work using the permission settings exposed by the desktop app. ### Additional information Control tests: - Bundled `cua_node` is Node.js v24.14.0 and is signed by OpenAI. - Outside the Codex sandbox, that exact bundled Node executable successfully spawns `cmd.exe` and prints `child-ok`. - Inside the Computer Use/Node sandbox, spawning `cmd.exe`, Node itself, or `codex-computer-use.exe` returns `EPERM`. - Updating system Node.js to v24.18.0 had no effect. - No matching Microsoft Defender, AppLocker, or current Code Integrity block was found. Runtime executables have valid signatures and readable/executable ACLs. The alternative elevated Windows sandbox also cannot initialize. The app displays “Windows setup didn't finish”. Setup creates sandbox users and WFP filters, then fails while adding a read ACE to the protected WindowsApps package directory: ```text grant read ACE failed ... for sandbox_group: SetNamedSecurityInfoW failed: 5 read ACL run completed with errors setup error: read ACL run had errors ``` Returning to unelevated mode removes the setup banner but Computer Use still fails with `spawn EPERM`. Related reports: - https://github.com/openai/codex/issues/21470 - https://github.com/openai/codex/issues/18451 - https://github.com/openai/codex/issues/18861 Please investigate the Windows sandbox child-process launch policy and the elevated sandbox setup's handling of protected WindowsApps ACLs.", "url": "https://github.com/openai/codex/issues/37415", "createdAt": "2026-08-07T09:12:44Z", "updatedAt": "2026-08-12T20:47:54Z", "timestamp": "2026-08-12T20:47:54Z", "metrics": { "reactions": 4, "comments": 13 }, "labels": [ "bug", "windows-os", "sandbox", "tool-calls", "app", "computer-use" ], "author": "Tuguldur0130", "state": "open", "assignees": [] }, { "id": "github:openai/codex:issue:37421", "source": "github", "group": "coding-agent-infrastructure", "project": "openai/codex", "kind": "issue", "title": "CLI 0.147.0: Esc-Esc backtrack cannot find selected prompt in persisted thread", "text": "### What version of Codex CLI is running? codex-cli 0.147.0 ### What subscription do you have? Max ### Which model were you using? gpt-5.6-sol ### What platform is your computer? Darwin 25.5.0 arm64 arm ### What terminal emulator and version are you using (if applicable)? iTerm2 3.6.11 ### What issue are you seeing? With an empty composer, using the Esc-Esc backtrack flow to select an earlier user prompt fails instead of creating a branch. Codex restores the selected prompt to the composer and shows: ```text Failed to branch before the selected prompt: the selected prompt was not found in the persisted thread ``` The selected prompt is visible in the transcript overlay, so the displayed history and the persisted thread used by the fork operation appear to be out of sync. ### What steps can reproduce the bug? 1. Start or resume an interactive Codex CLI session with multiple completed user prompts. 2. Leave the composer empty. 3. Press Esc twice to open the transcript/backtrack overlay. 4. Navigate to an earlier user prompt and press Enter to edit it. 5. Observe the error. Feedback was uploaded for the affected session: `019fdb75-1839-73d1-b40a-939a7e228e93`. ### What is the expected behavior? Codex should branch before the selected prompt and restore that prompt to the composer for editing. Any prompt displayed as a selectable backtrack target should resolve in the persisted thread. ### Additional information This was observed on the 0.147.0 release, which introduced paginated TUI transcript history. The full `codex doctor --json` output is intentionally omitted because it contains unrelated local session paths.", "url": "https://github.com/openai/codex/issues/37421", "createdAt": "2026-08-07T09:37:08Z", "updatedAt": "2026-08-13T15:48:43Z", "timestamp": "2026-08-13T15:48:43Z", "metrics": { "reactions": 36, "comments": 7 }, "labels": [ "bug", "TUI", "CLI", "session" ], "author": "PaulRBerg", "state": "closed", "assignees": [] }, { "id": "github:openai/codex:issue:37425", "source": "github", "group": "coding-agent-infrastructure", "project": "openai/codex", "kind": "issue", "title": "Regression in v0.147.0 with LiteLLM provider — streaming requests consistently fail", "text": "### What version of the Codex App are you using (From “About Codex” dialog)? v0.147.0 ### What subscription do you have? Custom litellm provider ### What platform is your computer? AlmaLinux 10.2 (Lavender Lion) ### What issue are you seeing? After upgrading Codex from `v0.146.0` to `v0.147.0`, all requests made through our LiteLLM-backed custom provider fail with the error: **\"We're currently experiencing high demand, which may cause temporary errors.\"** The internal logs repeatedly show `stream disconnected - retrying sampling request` in `codex_core::responses_retry` until the maximum number of retries is reached. Downgrading to `v0.146.0` immediately resolves the issue with no configuration changes. The same LiteLLM endpoint, credentials, models, and configuration work correctly on `v0.146.0`, which suggests a regression in `v0.147.0`, potentially related to streaming or Responses API handling with LiteLLM-compatible providers. ### What steps can reproduce the bug? 1. Configure Codex to use a LiteLLM-backed custom provider. 2. Run Codex with `v0.147.0`. 3. Submit any prompt. 4. The request fails after several retries with the `\"high demand\"` error. 5. Downgrade Codex to `v0.146.0` without changing the configuration. 6. Submit the same prompt again. 7. The request succeeds normally. ### What is the expected behavior? Requests should complete successfully with `v0.147.0`, using the same LiteLLM endpoint and configuration that work correctly with `v0.146.0`. ### Additional information I don't have access to the LiteLLM configuration, as it is managed through our corporate gateway. However, I can confirm that both `gpt-5.6-luna` and `gpt-5.6-terra` work correctly with other coding assistants using the same infrastructure, and they also work correctly with Codex `v0.146.0`. The issue only appears after upgrading to Codex `v0.147.0`. Downgrading back to `v0.146.0` immediately resolves it, which strongly indicates that the regression was introduced in `v0.147.0`. **Regression:** `v0.146.0` ✅ / `v0.147.0` ❌", "url": "https://github.com/openai/codex/issues/37425", "createdAt": "2026-08-07T09:52:31Z", "updatedAt": "2026-08-12T14:48:08Z", "timestamp": "2026-08-12T14:48:08Z", "metrics": { "reactions": 7, "comments": 5 }, "labels": [ "bug", "CLI", "custom-model", "app", "connectivity" ], "author": "CallisteH", "state": "open", "assignees": [], "change": "updated" }, { "id": "github:openai/codex:issue:37450", "source": "github", "group": "coding-agent-infrastructure", "project": "openai/codex", "kind": "issue", "title": "0.147-alpha (Windows): App keeps thread writer for every opened thread until full app exit; no attach path for external clients", "text": "0.147-alpha (Windows): App keeps thread writer for every opened thread until full app exit; no attach path for external clients Version: codex-cli 0.147.0-alpha.6.5 (Desktop App bundle), Windows 11 Pro 10.0.26200 Summary Since 0.147 introduced single-writer thread persistence, codex exec resume fails with: ERROR codex_core::session::session: failed to initialize thread persistence: thread-store conflict: thread already has an active writer whenever the Desktop App has ever opened that thread in the current app run. The writer is not released when the user navigates away from the thread — only a full app exit (including the tray process) releases it. Reproduction (verified step by step) Open thread X in the Desktop App → codex exec resume X \"hi\" → thread-store conflict. Expected? Arguably yes. Switch to a different thread in the App (thread X no longer displayed) → exec resume X → still conflict. Waiting several minutes does not help. Close the App window, tray process still running → still conflict. Fully quit the App (tray → exit) → exec resume X succeeds. Expected: the writer for thread X is released when the App navigates away from it (or after a short idle period), so CLI/SDK automation can continue threads the user merely viewed. Impact: any automation built on codex exec resume / the TypeScript SDK resumeThread() (e.g. local review loops that continue a long-lived thread) cannot run while the Desktop App is open if the target thread was viewed at any point. Users must fully restart the App before every automated turn. Related gap (Windows): there is currently no way to avoid the conflict by attaching to the App as a client instead: codex app-server daemon start and codex remote-control start → Error: codex app-server daemon lifecycle is only supported on Unix platforms The Desktop App on Windows does not expose the control socket (~/.codex/app-server-control/app-server-control.sock is absent; no listening TCP port or named pipe from the codex processes). Either releasing writers on thread switch or providing a Windows daemon/control socket (so external tools share the App's writer via the app-server protocol) would unblock this workflow.", "url": "https://github.com/openai/codex/issues/37450", "createdAt": "2026-08-07T14:29:09Z", "updatedAt": "2026-08-13T07:23:13Z", "timestamp": "2026-08-13T07:23:13Z", "metrics": { "reactions": 0, "comments": 2 }, "labels": [ "bug", "windows-os", "exec", "app", "session", "app-server" ], "author": "imaximov", "state": "open", "assignees": [] }, { "id": "github:openai/codex:issue:37458", "source": "github", "group": "coding-agent-infrastructure", "project": "openai/codex", "kind": "issue", "title": "# Codex extension fails to start: \"The extension couldn't load its resources\"", "text": "## Description The Codex panel fails to start after opening VSCode and shows: > Codex could not start. The extension couldn't load its resources. ## Environment - OS: Windows x64 - VSCode: 1.132.0 (commit `df53daabb18cd157bdb08c7f01c34df936cf12f4`) - Extension: `openai.chatgpt` 26.803.41515 (win32-x64) - Extension installed/updated: 2026-08-07 ## Steps to reproduce 1. Open VSCode. 2. Open the Codex sidebar or panel. 3. Wait about 30 seconds; the error \"Codex couldn't load its resources.\" appears. ## Console output (Developer Tools) Key error lines: ``` index.html?id=...&extensionId=openai.chatgpt... Loading the font 'data:font/woff2;base64,...' violates the following Content Security Policy directive: \"font-src 'self' https://*.vscode-cdn.net\". The action has been blocked. ... Codex couldn't load its resources. ``` ## Troubleshooting already tried - Developer: Reload Window - Fully quit and restart VSCode - Uninstall and reinstall the Codex extension - Cleared `%APPDATA%\\Code\\Service Worker\\CacheStorage` and `ScriptCache` - Tried to roll back the extension version, but \"Install Another Version...\" failed with \"Error while downloading VSIX: Canceled\" ## Additional analysis From the extension source, `initializeWebview` sets a 30-second startup timeout for the webview and requires a `ready` message within that window. If VSCode's CSP blocks the `data:font` resource, the frontend may fail to initialize and trigger this error. Please confirm compatibility between `26.803.41515` and VSCode `1.132.0`, and consider whether the webview's `data:font` should be served differently.", "url": "https://github.com/openai/codex/issues/37458", "createdAt": "2026-08-07T15:22:08Z", "updatedAt": "2026-08-13T12:47:08Z", "timestamp": "2026-08-13T12:47:08Z", "metrics": { "reactions": 11, "comments": 52 }, "labels": [ "bug", "windows-os", "extension" ], "author": "YeNai-ShaoXianChao", "state": "open", "assignees": [] }, { "id": "github:openai/codex:issue:37472", "source": "github", "group": "coding-agent-infrastructure", "project": "openai/codex", "kind": "issue", "title": "Allow request_user_input in Default mode to wait indefinitely", "text": "### What variant of Codex are you using? CLI ### What feature would you like to see? I'd like it to be possible to use `request_user_input` in Default mode without the question automatically resolving after a timeout. I have `request_user_input` explicitly enabled in Default mode using the `default_mode_request_user_input` feature. After updating to 0.147.0: `request_user_input` requests made outside Plan mode automatically resolve if I don't respond within a minute or two. It would be useful for Codex to support Default-mode `request_user_input` workflows where an unanswered question can remain pending until the user responds. ### Additional information This appears related to the recent change in #36410, which made blocking behavior of `request_user_input` explicit and currently classifies Plan-mode requests as blocking while requests from other enabled modes are non-blocking. There are related existing issues: * #34455 requests configurable `request_user_input` timeout duration and timeout behavior. * #28969 requests a way to disable automatic resolution of questions. * #29702 similarly requests a setting to disable timed auto-resolution. #34455 has a proposed solution that could resolve this too. I'm opening this issue separately because the behavior I'm seeing is specifically tied to Default mode: users can explicitly opt into `request_user_input` there via `default_mode_request_user_input`, but those requests are currently always non-blocking, with no way to opt into the blocking behavior used in Plan mode.", "url": "https://github.com/openai/codex/issues/37472", "createdAt": "2026-08-07T17:03:16Z", "updatedAt": "2026-08-13T00:58:08Z", "timestamp": "2026-08-13T00:58:08Z", "metrics": { "reactions": 1, "comments": 2 }, "labels": [ "enhancement", "CLI", "tool-calls" ], "author": "SimonPurdie", "state": "open", "assignees": [] }, { "id": "github:openai/codex:issue:37487", "source": "github", "group": "coding-agent-infrastructure", "project": "openai/codex", "kind": "issue", "title": "Codex CLI 0.147.0 Sends Empty Tool Description to Azure Responses API", "text": "### What version of Codex CLI is running? 0.147.0 ### What subscription do you have? Pro ### Which model were you using? _No response_ ### What platform is your computer? _No response_ ### What terminal emulator and version are you using (if applicable)? _No response_ ### Codex doctor report ```json ``` ### What issue are you seeing? After upgrading Codex CLI to 0.147.0, every prompt fails before inference when using Azure OpenAI Responses API: Invalid 'input[0].tools[0].description': empty string. Expected a string with minimum length 1, but got an empty string instead. Downgrading to 0.146.1 resolves the issue. ### What steps can reproduce the bug? Uploaded thread: 019fdd80-f401-7aa3-b4b4-137253e78e05 ### What is the expected behavior? _No response_ ### Additional information _No response_", "url": "https://github.com/openai/codex/issues/37487", "createdAt": "2026-08-07T18:38:48Z", "updatedAt": "2026-08-13T14:32:40Z", "timestamp": "2026-08-13T14:32:40Z", "metrics": { "reactions": 3, "comments": 10 }, "labels": [ "bug", "azure", "CLI", "tool-calls" ], "author": "AdityaVishwakarmaIN", "state": "open", "assignees": [] }, { "id": "github:openai/codex:issue:37493", "source": "github", "group": "coding-agent-infrastructure", "project": "openai/codex", "kind": "issue", "title": "macOS desktop app ≥26.730 crash-loops on launch on 16 GB Apple Silicon Mac (V8 crash ~6–15 s after launch); same builds fine on 48 GB machine", "text": "## Summary Every build from 26.730.61639 onward crash-loops on launch on one of my Macs, while the identical builds run fine on another. 26.727.51351 is the last build that works on the affected machine. - **26.730.61639 (Sparkle 6234):** crashes ~6 s after launch — V8 \"JavaScript heap out of memory\", faulting thread CrBrowserMain. - **26.803.41515 (Sparkle 6321):** crashes ~6–15 s after launch — EXC_BREAKPOINT (SIGTRAP) in V8, faulting thread V8Worker. Both crash reports attached. ## Environment comparison (why I believe it's memory-related) | | Affected machine | Working machine | |---|---|---| | Model | MacBook (Apple Silicon) | Mac mini 2024 (M4 Pro) | | RAM | **16 GB** | **48 GB** | | macOS | 26.2 → updated to **26.6.1 (25G76)** | 26.3.1(a) | | Result | Crashes on 26.730 and 26.803 | Both builds run fine | ## Ruled out - **User-level state:** launching with a fresh `CODEX_HOME` and fresh Application Support still crashes. - **Corrupt download / Sparkle delta:** performed a clean direct install of 26.803 from the full appcast zip (`ChatGPT-darwin-arm64-26.803.41515.zip`, size verified, `codesign -v --deep` passes) — still crashes. - **macOS version:** updated the affected machine from 26.2 to 26.6.1 — *newer* than the working machine's OS — and 26.803 still crashes with the identical signature. The only remaining differences are hardware — most notably 16 GB vs 48 GB RAM. Since V8 sizes its default heap relative to system memory, a launch-time allocation that fits within the larger heap cap on a 48 GB machine could exhaust the smaller cap on a 16 GB machine, which matches the 26.730 heap-OOM signature. ## Crash signatures 26.730.61639 — faulting thread CrBrowserMain: ``` V8 JavaScript heap out of memory (full .ips attached) ``` 26.803.41515 — faulting thread V8Worker: ``` EXC_BREAKPOINT (SIGTRAP) frames in Codex Framework: v8::CppHeap::CollectGarbageInYoungGeneration…, v8::internal::compiler::CompilationDependencies::DependOnElementsKind, … (full .ips attached) ``` ## Steps to reproduce (affected machine) 1. Install 26.730 or later on a 16 GB Apple Silicon Mac (macOS 26.2 or 26.6.1). 2. Launch the app. No interaction needed. 3. App quits ~6–15 s after launch; relaunches via crash recovery and dies again (crash loop). ## Workaround Pinned to 26.727.51351: `chflags uchg` on the bundle + `SUFeedURL` pointed at localhost to block Sparkle. Works, but means no updates. Happy to provide more diagnostics, run instrumented builds, or test a fix. --- *Full `.ips` crash reports for both builds available — will attach in a comment.*", "url": "https://github.com/openai/codex/issues/37493", "createdAt": "2026-08-07T19:36:53Z", "updatedAt": "2026-08-12T20:56:14Z", "timestamp": "2026-08-12T20:56:14Z", "metrics": { "reactions": 0, "comments": 3 }, "labels": [ "bug", "app", "performance" ], "author": "pkruger1977", "state": "closed", "assignees": [] }, { "id": "github:openai/codex:issue:37502", "source": "github", "group": "coding-agent-infrastructure", "project": "openai/codex", "kind": "issue", "title": "[Windows][Codex Security 0.1.18] Deep Scan fails because in-scope inventory preserves .\\ paths", "text": "### What version of the Codex App are you using (From “About Codex” dialog)? 26.803.41515 ### What subscription do you have? ChatGPT Business ### What platform is your computer? Microsoft Windows NT 10.0.26200.0 x64 ### What issue are you seeing? Codex Security Deep Scan fails on Windows before discovery because `codex-security 0.1.18` writes the native Windows path spelling returned by `ripgrep` directly into its in-scope inventory. With repository scope `.`, the Codex-bundled `ripgrep 15.2.0` returns paths such as: ```text .\\src\\example.txt ``` `codex-security/0.1.18/scripts/generate_in_scope_files.py` preserves this value unchanged. The relevant implementation invokes: ```python command = [\"rg\", \"--files\", \"--hidden\", \"--glob\", \"!.git/**\", \"--\", scope] ``` The resulting inventory is then only rewound and sorted: ```python inventory.seek(0) rows = sorted(inventory) ``` and written unchanged: ```python handle.writelines(rows) ``` There is no platform-independent path canonicalization between the `ripgrep` output and the inventory writer. In the affected Deep Security Scan, downstream inventory validation rejected the generated Windows-formatted entries because they contained backslashes and leading `.` path segments. The scan failure analysis reported: - 1,182 generated in-scope paths - 1,182 paths violating the inventory path requirements - terminal scan status: `failed` - failure before discovery workers started The failed logical Deep Scan could not be resumed. Environment: - Codex App (About dialog): `26.803.41515` - MSIX/AppX package: `OpenAI.Codex 26.803.5235.0` - Embedded Codex CLI: `codex-cli 0.147.0-alpha.6.5` - Codex Security plugin: `0.1.18` - Codex-bundled ripgrep: `ripgrep 15.2.0 (rev e89fff89ac)` - PowerShell: `7.6.4` - Windows x64 No repository files were modified during reproduction or diagnosis. ### What steps can reproduce the bug? The faulty inventory serialization can be reproduced without the original repository and without starting another Security Scan. # 1. Create an isolated temporary test directory ```powershell $TestRoot = Join-Path $env:TEMP \"codex-rg-path-test\" Remove-Item $TestRoot -Recurse -Force -ErrorAction SilentlyContinue New-Item -ItemType Directory $TestRoot | Out-Null New-Item -ItemType Directory (Join-Path $TestRoot \"src\") | Out-Null \"test\" | Set-Content (Join-Path $TestRoot \"src\\example.txt\") ``` # 2. Locate the `ripgrep` binary bundled with Codex The affected Codex installation contains its own `rg.exe`. A portable way to locate it is: ```powershell $Rg = Get-ChildItem \"$env:LOCALAPPDATA\\OpenAI\\Codex\\bin\" ` -Filter \"rg.exe\" ` -File ` -Recurse ` -ErrorAction Stop | Sort-Object LastWriteTime -Descending | Select-Object -First 1 -ExpandProperty FullName & $Rg --version ``` Observed version: ```text ripgrep 15.2.0 (rev e89fff89ac) features:+pcre2 simd(compile):+SSE2,-SSSE3,-AVX2 simd(runtime):+SSE2,+SSSE3,+AVX2 PCRE2 10.45 is available (JIT is available) ``` # 3. Run the same `ripgrep` arguments used by the plugin ```powershell Push-Location $TestRoot try { $Rows = @(& $Rg --files --hidden --glob \"!.git/**\" -- .) Write-Host \"Raw ripgrep output:\" $Rows Write-Host \"`nBackslash count:\" @($Rows | Where-Object { $_ -match '\\\\' }).Count Write-Host \"`nLeading dot-segment count:\" @($Rows | Where-Object { $_ -match '^\\.[\\\\/]' }).Count Write-Host \"`nRows:\" $Rows.Count } finally { Pop-Location } ``` Observed output: ```text Raw ripgrep output: .\\src\\example.txt Backslash count: 1 Leading dot-segment count: 1 Rows: 1 ``` This confirms that the Codex-bundled `ripgrep` returns the native Windows path spelling for repository scope `.`. ### 4. Run the actual Codex Security inventory generator Use the actual generator from Codex Security 0.1.18: ```text codex-security/0.1.18/scripts/generate_in_scope_files.py ``` The script invokes `rg` by name, so make the directory containing Codex's bundled `rg.exe` available only to the current PowerShell process for the duration of this test: ```powershell $OldPath = $env:PATH try { $env:PATH = \"$(Split-Path $Rg);$env:PATH\" $PluginScript = \"$env:USERPROFILE\\.codex\\plugins\\cache\\openai-curated-remote\\codex-security\\0.1.18\\scripts\\generate_in_scope_files.py\" $OutputFile = Join-Path $TestRoot \"inventory.txt\" Remove-Item $OutputFile -Force -ErrorAction SilentlyContinue python $PluginScript ` --repo $TestRoot ` --scope \".\" ` --out $OutputFile $InventoryRows = @(Get-Content $OutputFile) Write-Host \"`nGenerated inventory:\" $InventoryRows Write-Host \"`nBackslash count:\" @($InventoryRows | Where-Object { $_ -match '\\\\' }).Count Write-Host \"`nLeading dot-segment count:\" @($InventoryRows | Where-Object { $_ -match '^\\.[\\\\/]' }).Count Write-Host \"`nRows:\" $InventoryRows.Count } finally { $env:PATH = $OldPath } ``` Observed output: ```text Recorded 1 in-scope files. Generated inventory: .\\src\\example.txt Backslash count: 1 Leading dot-segment count: 1 Rows: 1 ``` This demonstrates that `generate_in_scope_files.py` preserves the native Windows `ripgrep` path spelling unchanged. The real Deep Scan subsequently failed when its downstream inventory validation processed the same path representation. ### What is the expected behavior? Codex Security should serialize in-scope inventory entries into a canonical, repository-relative representation independent of the host operating system. For example: ```text .\\src\\example.txt ``` should be serialized as: ```text src/example.txt ``` The generated inventory should contain: - repository-relative paths - `/` path separators - no `.` path components - no `..` traversal components - no absolute paths The same repository and scan scope should produce equivalent canonical inventory semantics on Windows and POSIX hosts. A Deep Security Scan should not enter terminal `failed` state before discovery because of host-specific path spelling produced by its bundled search tool. ### Additional information `resolve_scope()` also contributes to this behavior because relative scopes are returned unchanged: ```python def resolve_scope(repository: Path, value: str) -> str: ... if requested.is_absolute(): return relative.as_posix() if relative.parts else \".\" return value ``` Therefore the normal repository-root scope: ```text . ``` remains `\".\"` and is passed directly to `ripgrep`. The relevant generator flow is therefore: ```text scope \".\" | v rg --files --hidden --glob !.git/** -- . | v .\\src\\example.txt | v inventory.seek(0) rows = sorted(inventory) | v handle.writelines(rows) | v .\\src\\example.txt | v downstream inventory validation | v Deep Scan FAILED ``` ### Suggested fix Canonicalize and validate every path returned by `ripgrep` before writing the inventory. A simple string replacement alone should not be the complete security boundary. The canonicalization should: 1. require repository-relative paths; 2. reject absolute paths; 3. reject `..` traversal components; 4. remove `.` components; 5. serialize with `/` separators. For example: ```text Raw Windows result: .\\src\\subdir\\file.py Canonical inventory: src/subdir/file.py ``` ### Suggested regression tests #### Windows repository-root scope Input: ```text .\\src\\file.py ``` Expected: ```text src/file.py ``` #### Nested Windows path Input: ```text .\\src\\subdir\\file.py ``` Expected: ```text src/subdir/file.py ``` #### Inventory invariants Assert: ```text backslashes = 0 \".\" path segments = 0 \"..\" segments = 0 absolute paths = 0 ``` #### Cross-platform invariant The same repository and scope should produce equivalent canonical inventory entries on Windows, Linux, and macOS. ### Impact observed in the real scan The affected Deep Security Scan reported: - 1,182 generated inventory entries - 1,182 entries violating the validator's path requirements - terminal state `failed` - failure before discovery workers started - no usable Deep Scan result - the failed logical scan could not be resumed This is particularly disruptive because setup/model usage can be consumed before actual security discovery begins, and a replacement scan must be started after remediation. ### Separate Windows sandbox issue Windows sandbox / command-runner fallback approval messages were also observed during the same Codex session. Those appear to be a separate Windows Codex issue and are intentionally excluded from this report so that the inventory path bug remains independently reproducible and attributable. ### Additional version information: - MSIX/AppX package: `OpenAI.Codex 26.803.5235.0` - Embedded Codex CLI: `codex-cli 0.147.0-alpha.6.5`", "url": "https://github.com/openai/codex/issues/37502", "createdAt": "2026-08-07T20:50:32Z", "updatedAt": "2026-08-12T16:50:08Z", "timestamp": "2026-08-12T16:50:08Z", "metrics": { "reactions": 0, "comments": 1 }, "labels": [ "bug", "windows-os", "app", "safety-check", "skills" ], "author": "Foo-Fighter", "state": "open", "assignees": [] }, { "id": "github:openai/codex:issue:37540", "source": "github", "group": "coding-agent-infrastructure", "project": "openai/codex", "kind": "issue", "title": "Add Model/Speed/Subagent count to activity view sidebar", "text": "### What variant of Codex are you using? App ### What feature would you like to see? Would be nice to see a little more info on the activity view - consider adding the model (to understand which things are running with low vs high thinking), speed (to understand which things are costing more usage, and subagent count (to understand which things have potentially much larger fanout cost) ### Additional information _No response_", "url": "https://github.com/openai/codex/issues/37540", "createdAt": "2026-08-08T05:29:14Z", "updatedAt": "2026-08-12T15:14:56Z", "timestamp": "2026-08-12T15:14:56Z", "metrics": { "reactions": 0, "comments": 1 }, "labels": [ "enhancement", "app" ], "author": "joshka", "state": "open", "assignees": [], "change": "updated" }, { "id": "github:openai/codex:issue:37551", "source": "github", "group": "coding-agent-infrastructure", "project": "openai/codex", "kind": "issue", "title": "chat open in new window shows something went wrong", "text": "### What version of the Codex App are you using (From “About Codex” dialog)? Version 26.721.81911 ### What subscription do you have? chatgpt pro ### What platform is your computer? _No response_ ### What issue are you seeing? \"Image\" click on 'open in new window' will show this error: something went wrong ### What steps can reproduce the bug? click on 'open in new window' will show this error: something went wrong ### What is the expected behavior? _No response_ ### Additional information _No response_", "url": "https://github.com/openai/codex/issues/37551", "createdAt": "2026-08-08T07:34:51Z", "updatedAt": "2026-08-13T10:51:59Z", "timestamp": "2026-08-13T10:51:59Z", "metrics": { "reactions": 1, "comments": 4 }, "labels": [ "bug", "app" ], "author": "lytruby", "state": "open", "assignees": [] }, { "id": "github:openai/codex:issue:37567", "source": "github", "group": "coding-agent-infrastructure", "project": "openai/codex", "kind": "issue", "title": "Qonto MCP regression in 0.147.0: startup completes without caching or exposing tools", "text": "### What version of Codex is running? - Codex CLI 0.146.0: Qonto MCP works - Codex CLI 0.147.0: Qonto MCP initialization fails - Codex Desktop client version observed in logs: 26.803.41515 (internal traces reference client version 0.147.0) ### What operating system are you using? macOS 26.5.2 (25F84) ### What is the issue? Qonto MCP tools are missing in Codex 0.147.0 although OAuth succeeds and the same MCP server works in Codex CLI 0.146.0. Internal logs show: ```text MCP server tools unavailable while building tool list server_name=qonto has_cached_tools=false startup_complete=true ``` The keychain credentials are loaded successfully, but the server is later omitted with: ```text omitting MCP server without an exact ready client server_name=qonto ``` ### MCP configuration ```toml [mcp_servers.qonto] url = \"https://mcp.qonto.com/mcp\" ``` - Endpoint: `https://mcp.qonto.com/mcp` - Server identity: `mcp-qonto` version `0.2.0` - Negotiated protocol version: `2025-06-18` ### Steps to reproduce 1. Configure the Qonto MCP endpoint above. 2. Run `codex mcp login qonto` and complete OAuth successfully. 3. Start a new Codex Desktop conversation or Codex CLI 0.147.0 session. 4. Request a Qonto tool such as `qonto/get_organization`. 5. Observe that Qonto tools are unavailable or that Qonto is reported among MCP servers that failed to initialize. 6. Reauthentication and new conversations do not fix the issue. ### Control tests - An authenticated raw MCP `initialize` request returns HTTP 200 with `text/event-stream`. - The response advertises tools with `listChanged: true`. - An authenticated `tools/list` request returns 56 tools. - Codex CLI 0.146.0, using the same global configuration and keychain credentials, successfully executes: ```text mcp: qonto/get_organization started mcp: qonto/get_organization (completed) ``` - Immediately after updating the CLI to 0.147.0, startup reports: ```text MCP startup incomplete (failed: ..., qonto) ``` - Other MCP integrations, including OpenAI documentation and authenticated Linear, work. ### Expected behavior Codex should register and expose the tools returned by Qonto's `tools/list`. The 0.146.0 success versus 0.147.0 failure strongly suggests a regression in the 0.147.0 MCP connection manager or deferred tool catalog. A characteristic of Qonto's response may trigger the defect, but it is accepted by 0.146.0 and by direct standards-compliant MCP calls. ### Feedback reference Private Codex feedback thread: `019fe0cb-7026-78a2-9880-95e0dccc7381` No credentials, organization names, bank identifiers, UUIDs, transactions, or accounting data are included.", "url": "https://github.com/openai/codex/issues/37567", "createdAt": "2026-08-08T09:59:00Z", "updatedAt": "2026-08-13T09:53:44Z", "timestamp": "2026-08-13T09:53:44Z", "metrics": { "reactions": 1, "comments": 3 }, "labels": [ "bug", "mcp", "CLI" ], "author": "dperetti", "state": "open", "assignees": [] }, { "id": "github:openai/codex:issue:37584", "source": "github", "group": "coding-agent-infrastructure", "project": "openai/codex", "kind": "issue", "title": "[Windows] Desktop app 26.803.41515: memory leak → silent crashes, UI desyncs from backend, project threads never load", "text": "### What version of the Codex App are you using (From “About Codex” dialog)? Desktop app 26.803.41515 ### What subscription do you have? chatgpt pro ### What platform is your computer? windows ### What issue are you seeing? Since the 26.803.41515 build (released Aug 7, 2026) arrived on this machine, the Windows desktop app has become unusable for Work/project sessions: turns hang at \"Thinking\" forever, project threads show an infinite spinner and never render, the whole UI becomes progressively laggier, and the app eventually exits silently (no crash dialog). Evidence below shows the backend (app-server) keeps working correctly the whole time — this is a renderer/UI-process problem, preceded by OS-level memory-leak flags on both ChatGPT.exe and codex.exe. Everything worked normally through the evening of Aug 7 (daily scheduled automations completed at 10:32Z and 11:32Z on Aug 7). Symptoms began midday Aug 8, the first day after this build was installed. Environment App: ChatGPT (Codex) Desktop for Windows 26.803.41515 (MSIX package 26.803.5235.0), released 2026-08-07, Microsoft Store install Runtime/plugins: codex-primary-runtime 26.805.11740 (auto-downloaded); command-runner 0.147.0-alpha.6.5 OS: Windows 11 build 10.0.26200.8875, x64 Hardware: Surface laptop, 32 GB RAM (≈20 GB free at idle), Intel Iris Plus + NVIDIA GTX 1660 Ti Max-Q Network: backend traffic via HTTP_PROXY/HTTPS_PROXY to a local proxy (127.0.0.1:7897). Verified healthy: fresh-start turns complete end-to-end in ~16–18 s, websocket to wss://chatgpt.com/backend-api/codex/responses connects and streams. Timeline Aug 6–7 (while still working): Windows Error Reporting logged RADAR_PRE_LEAK_64 (OS memory-leak detector) for ChatGPT.exe (2026-08-06 23:45 UTC, Electron 151.0.7922.71) and codex.exe (2026-08-07 00:00 UTC). Aug 7 evening: last fully-normal day; scheduled automations completed. Aug 8 midday onward: every Work turn in every project sticks at \"Thinking\"; opening any existing project thread shows an infinite spinner; app exits silently after minutes of use. Key evidence 1. Silent UI-process death (no fault recorded). The app-server log (~/.codex/logs_2.sqlite) simply stops mid-stream at crash time (e.g., 2026-08-08 11:35:57 UTC: last rows are routine WARN/DEBUG, then nothing). Windows Application event log has no Event 1000 for these exits — process death without an access violation, consistent with memory exhaustion, not a classic crash. 2. Backend keeps working while the UI shows an infinite spinner (state desync, cf. #24287). At 2026-08-08 12:21 UTC, while the UI displayed an endless spinner for a small test thread: resume_thread_with_history → thread_spawn → list_models all succeeded (models cache hit), websocket connected to wss://chatgpt.com/backend-api/codex/responses and streamed response.in_progress / metadata events, a scheduled automation turn executed to completion in the background. The renderer never displayed any of it. After an app restart, previously \"stuck\" turns show up as completed. 3. Repeated error during thread resume: resume_thread_with_history:thread_spawn:list_models{refresh_strategy=online_if_uncached}: failed to refresh available models: timeout waiting for child process to exit 4. Ruled out local causes (none changed the behavior): Cleared bloated logs_2.sqlite (440 MB + 131 MB WAL) and stale thread-writer-locks/*.lock Reset ~/.cache/codex-runtimes (runtime re-downloaded cleanly) Moved 1,200+ files out of ~/.codex/generated_images MSIX Repair and Reset of the app; Microsoft Store repaired; confirmed app is the latest available build Verified network path end-to-end (turns complete normally right after a fresh app start) 5. Long-standing sandbox warnings (present on healthy days too, likely unrelated but noting for completeness): hide users: failed to hide current user profile dir (C:\\Users\\Default): SetFileAttributesW failed ... 5 (access denied) — thousands of occurrences across days; junction: failed to create C:\\Users\\Default\\.codex\\.sandbox\\cwd: access denied (os error 5) — several per day. Repro (as observed) Launch app; first minutes behave normally (turns complete). Use Work sessions for a few minutes, or open a large/older project thread. UI detaches: new turns stick at \"Thinking\", thread views spin forever; memory grows. App eventually exits silently. Restart temporarily restores normal behavior; degradation repeats. Expected Turns render as they stream; project threads open; UI process does not leak/die. Notes Happy to provide the logs_2.sqlite extracts, sandbox logs, and WER references on request. ### What steps can reproduce the bug? [Windows] Desktop app 26.803.41515: memory leak → silent crashes, UI desyncs from backend, project threads never load ### What is the expected behavior? _No response_ ### Additional information _No response_", "url": "https://github.com/openai/codex/issues/37584", "createdAt": "2026-08-08T12:36:55Z", "updatedAt": "2026-08-13T13:29:32Z", "timestamp": "2026-08-13T13:29:32Z", "metrics": { "reactions": 0, "comments": 2 }, "labels": [ "bug", "windows-os", "app", "performance" ], "author": "Teemo-Kingdom", "state": "open", "assignees": [] }, { "id": "github:openai/codex:issue:37587", "source": "github", "group": "coding-agent-infrastructure", "project": "openai/codex", "kind": "issue", "title": "Codex Security: recoverable finalization schema error permanently fails completed scan", "text": "### Summary A Codex Security diff scan completed discovery, validation, attack-path analysis, and canonical draft generation, but finalization rejected an empty `scan.target.snapshotDigest`. After repairing the digest in a fresh turn, completion could not be retried because the first validation error had already moved the scan into the terminal `failed` state. This makes a recoverable metadata/schema error permanently prevent sealing an otherwise completed long-running scan. ### Environment - Codex desktop on Windows with Ubuntu/WSL 2 - Codex Security plugin: `0.1.17` when the scan began; `0.1.18` subsequently installed - Scan mode: Git revision-range/diff scan - Exact base and head revisions were available throughout - Repository checkout remained unchanged Private scan identifiers and unsealed artifacts can be provided privately if needed. ### Reproduction 1. Start a Codex Security diff scan over an exact base/head revision range. 2. Complete all review receipts and the validation and attack-path phases. 3. Author the canonical unsealed draft artifacts. 4. Call scan completion. 5. Completion fails with: ``` scan.target.snapshotDigest: expected a non-empty string ``` 6. In a fresh turn, populate the correct deterministic snapshot digest and verify the canonical artifacts. 7. Call completion once more. 8. Completion fails with: ``` Only a running scan can be completed. ``` The first finalization validation error has already marked the scan `failed`, and the exposed workflow has no supported `failed → running` recovery transition. ### Expected behavior One or more of the following: - Populate and validate `snapshotDigest` before attempting terminal finalization. - Treat canonical artifact/schema validation errors as recoverable and leave the scan running. - Make finalization transactional so a validation failure does not persist terminal state. - Provide an audited recovery/reopen operation for scans whose artifacts are repaired after a finalization error. ### Actual behavior The expensive analytical phases and valid draft artifacts remain available, but the scan cannot be sealed or displayed as completed. The only supported alternative appears to be rerunning the entire scan. ### Additional context The installed `0.1.18` package documents `snapshotDigest` as required for Git diff targets, but includes no recovery procedure for this terminal state. The public Codex Security changelog currently stops at `0.1.17`. No repository contents, finding details, local paths, scan identifiers, or sensitive artifacts are included in this issue.", "url": "https://github.com/openai/codex/issues/37587", "createdAt": "2026-08-08T13:12:50Z", "updatedAt": "2026-08-13T07:20:01Z", "timestamp": "2026-08-13T07:20:01Z", "metrics": { "reactions": 1, "comments": 2 }, "labels": [ "bug", "app", "safety-check", "skills" ], "author": "caseypettingill", "state": "open", "assignees": [] }, { "id": "github:openai/codex:issue:37591", "source": "github", "group": "coding-agent-infrastructure", "project": "openai/codex", "kind": "issue", "title": "Codex App branch switch uses a different worktree than the task terminal", "text": "### Summary The Codex macOS app can appear to use different Git worktree contexts for the terminal and branch-switch UI within the same task. ### Reproduction 1. Start a Codex task from a Git repository using a managed worktree. 2. In the task terminal, run: ``` pwd git branch --show-current ``` The terminal reports a managed worktree path such as `/Users//.codex/worktrees/7e31/WantPic` and branch `ft/blog_image`. 3. In the Codex app's branch switcher, select `ft/blog_image`. 4. The app reports: ``` fatal: 'ft/blog_image' is already used by worktree at '/Users//.codex/worktrees/WantPic' ``` 5. `git worktree list` shows the branch is already attached to the managed task worktree, while the main checkout remains on another branch. 6. Restarting the ChatGPT/Codex app initially restores the expected branch, but resuming/reconnecting to this task causes the wrong branch context to return. ### Expected behavior The branch controls and task terminal should resolve the same repository/worktree context. Resuming a task should preserve its associated worktree and branch. ### Actual behavior The task environment can alternate between the managed feature branch and the main branch. The branch-switch operation appears to resolve a different or stale worktree path and rejects the feature branch as already in use. ### Screenshot evidence The supplied screenshots show the following sequence: - `Screenshot 2026-08-08 at 10.54.19 PM.png`: the Environment panel shows `1.10.0/master`. - `Screenshot 2026-08-08 at 10.54.47 PM.png`: it shows `ft/blog_image`, the commit `[1.10.0] 블로그 썸네일 추가`, and one comment. - `Screenshot 2026-08-08 at 10.55.05 PM.png`: it has returned to `1.10.0/master`. This alternating state occurs while working with the same task and is consistent with the task being rebound to the wrong worktree after resume/reconnect. ### Additional context (hypothesis) The problem did not occur when the worktree and task were first created. It may correlate with reconnecting to the repository remotely and/or reopening the task from a remote session. This is a suspicion rather than a confirmed cause, but it may help narrow down when the repository/worktree context becomes stale or inconsistent. ### Environment - ChatGPT macOS app (Version 26.803.41515) - macOS (26.5.2) - Git worktrees enabled \"Image\" \"Image\" \"Image\"", "url": "https://github.com/openai/codex/issues/37591", "createdAt": "2026-08-08T13:59:07Z", "updatedAt": "2026-08-12T18:49:45Z", "timestamp": "2026-08-12T18:49:45Z", "metrics": { "reactions": 0, "comments": 3 }, "labels": [ "bug", "app", "session" ], "author": "funct7", "state": "open", "assignees": [] }, { "id": "github:openai/codex:issue:37592", "source": "github", "group": "coding-agent-infrastructure", "project": "openai/codex", "kind": "issue", "title": "Windows sandbox inconsistently fails to start PowerShell with CreateProcessAsUserW error 5", "text": "### What version of the Codex App are you using (From “About Codex” dialog)? Version 26.803.41515 ### What subscription do you have? ChatGPT Pro ### What platform is your computer? Microsoft Windows NT 10.0.26200.0 x64 ### What issue are you seeing? [REPORTE_PUBLICO_GITHUB_CODEX_WINDOWS.md](https://github.com/user-attachments/files/30856982/REPORTE_PUBLICO_GITHUB_CODEX_WINDOWS.md) ### What steps can reproduce the bug? The Codex Windows app intermittently fails to launch PowerShell commands inside its workspace-write sandbox. The exact error is: windows sandbox: CreateProcessAsUserW failed: 5 (Acceso denegado.) The affected PowerShell executable is resolved through: %LOCALAPPDATA%\\Microsoft\\WindowsApps\\pwsh.exe The same Windows account, Codex app version, configuration, and local environment can work correctly in one task but fail in another task. When the failure occurs, even simple read-only PowerShell commands cannot start because the process is rejected before the command executes. This prevents Codex from inspecting, editing, testing, or validating the workspace and therefore prevents normal use of the paid service. Repeated attempts made while diagnosing this Codex sandbox failure have also consumed paid usage. The relevant configuration is: sandbox_mode = \"workspace-write\" [windows] sandbox = \"unelevated\" No personal filesystem paths, account identifiers, session identifiers, or credentials are included in this public report. ### What is the expected behavior? 1. Open Codex App version 26.803.41515 on Windows x64. 2. Open a local project using workspace-write mode with the Windows sandbox set to unelevated. 3. Start a task and ask Codex to execute a simple read-only PowerShell command such as Get-Location. 4. Codex attempts to launch pwsh.exe through the WindowsApps alias. 5. The process can fail before the command executes with: windows sandbox: CreateProcessAsUserW failed: 5 (Acceso denegado.) 6. Open another Codex task or project using the same Windows account and configuration. 7. The same command may work there, demonstrating inconsistent sandbox process-launch behavior between tasks. ### Additional information A sanitized public diagnostic report is attached to this issue. The in-app slash menu did not show a feedback or problem-reporting option in this installation, so this issue is being submitted through the official Codex GitHub repository. Please investigate the Windows sandbox permission state and the inconsistent CreateProcessAsUserW behavior. Please also advise the appropriate channel for an account-level review of paid usage consumed by repeated failed attempts caused by this app error, and restore that usage if applicable. The failure was reproduced again on 08-08-2026 when Codex attempted to run a simple local read-only PowerShell command. The command never started and returned the same CreateProcessAsUserW error 5.", "url": "https://github.com/openai/codex/issues/37592", "createdAt": "2026-08-08T14:14:30Z", "updatedAt": "2026-08-12T17:11:48Z", "timestamp": "2026-08-12T17:11:48Z", "metrics": { "reactions": 0, "comments": 3 }, "labels": [ "bug", "windows-os", "sandbox", "tool-calls", "app" ], "author": "teknovaltda-prog", "state": "open", "assignees": [] }, { "id": "github:openai/codex:issue:37598", "source": "github", "group": "coding-agent-infrastructure", "project": "openai/codex", "kind": "issue", "title": "session renders properly in codex cli but improperly in chatgpt remote (android)", "text": "### What version of Codex CLI is running? codex-cli 0.147.0 ### What subscription do you have? pro $100 ### Which model were you using? gpt-5.6-sol max ### What platform is your computer? Linux 7.0.11-76070011-generic x86_64 x86_64 ### What terminal emulator and version are you using (if applicable)? https://github.com/pop-os/cosmic-term (alacritty based) ### Codex doctor report ```json { \"schemaVersion\": 1, \"generatedAt\": \"1786200913s since unix epoch\", \"overallStatus\": \"warning\", \"codexVersion\": \"0.147.0\", \"checks\": { \"app_server.status\": { \"id\": \"app_server.status\", \"category\": \"app-server\", \"status\": \"ok\", \"summary\": \"background server is running\", \"details\": { \"app-server version\": \"0.146.0\", \"control socket\": \"/home/nick/.codex/app-server-control/app-server-control.sock\", \"daemon state dir\": \"/home/nick/.codex/app-server-daemon\", \"mode\": \"persistent\", \"pid file\": \"/home/nick/.codex/app-server-daemon/app-server.pid (file)\", \"settings\": \"/home/nick/.codex/app-server-daemon/settings.json (file)\", \"status\": \"running\", \"update-loop pid file\": \"/home/nick/.codex/app-server-daemon/app-server-updater.pid (file)\" }, \"remediation\": null, \"durationMs\": 48 }, \"auth.credentials\": { \"id\": \"auth.credentials\", \"category\": \"auth\", \"status\": \"ok\", \"summary\": \"auth is configured\", \"details\": { \"auth file\": \"/home/nick/.codex/auth.json\", \"auth storage mode\": \"File\", \"stored API key\": \"false\", \"stored ChatGPT tokens\": \"true\", \"stored agent identity\": \"false\", \"stored auth mode\": \"chatgpt\" }, \"remediation\": null, \"durationMs\": 0 }, \"config.load\": { \"id\": \"config.load\", \"category\": \"config\", \"status\": \"ok\", \"summary\": \"config loaded\", \"details\": { \"CODEX_HOME\": \"/home/nick/.codex\", \"config.toml\": \"/home/nick/.codex/config.toml\", \"config.toml parse\": \"ok\", \"cwd\": \"/home/nick/git/read\", \"enabled feature flags\": \"shell_tool, view_image, unified_exec, shell_snapshot, code_mode_host, terminal_resize_reflow, sqlite, hooks, enable_request_compression, multi_agent, apps, tool_search_always_defer_mcp_tools, tool_suggest, plugins, in_app_browser, in_app_updates, browser_use, browser_use_full_cdp_access, browser_use_external, computer_use, remote_plugin, plugin_sharing, image_generation, resize_all_images, item_ids, skill_mcp_dependency_install, skill_search, mentions_v2, steer, guardian_approval, goals, collaboration_modes, tool_call_mcp_elicitation, auth_elicitation, personality, fast_mode, tui_app_server, remote_compaction_v2, workspace_dependencies\", \"feature flag overrides\": \"none\", \"feature flags enabled\": \"39\", \"log dir\": \"/home/nick/.codex/log\", \"mcp servers\": \"1\", \"model\": \"gpt-5.6-sol\", \"model provider\": \"openai\", \"sqlite home\": \"/home/nick/.codex\" }, \"remediation\": null, \"durationMs\": 0 }, \"git.environment\": { \"id\": \"git.environment\", \"category\": \"git\", \"status\": \"ok\", \"summary\": \"git version 2.43.0\", \"details\": { \".git entry\": \"directory\", \"PATH git #1\": \"/usr/bin/git\", \"PATH git #2\": \"/bin/git\", \"PATH git entries\": \"2\", \"git branch\": \"master\", \"git build options\": \"git version 2.43.0; cpu: x86_64; no commit associated with this build; sizeof-long: 8; sizeof-size_t: 8; shell-path: /bin/sh\", \"git exec path\": \"/usr/lib/git-core\", \"git version\": \"git version 2.43.0\", \"repo detected\": \"true\", \"repo root\": \"/home/nick/git/read\", \"selected git\": \"/usr/bin/git\" }, \"remediation\": null, \"durationMs\": 37 }, \"installation\": { \"id\": \"installation\", \"category\": \"install\", \"status\": \"ok\", \"summary\": \"installation looks consistent\", \"details\": { \"PATH codex #1\": \"/home/nick/.local/bin/codex\", \"PATH codex #2\": \"/home/nick/.local/bin/codex\", \"PATH codex entries\": \"2\", \"current executable\": \"/home/nick/.codex/packages/standalone/releases/0.147.0-x86_64-unknown-linux-musl/bin/codex\", \"install context\": \"standalone (unix, package /home/nick/.codex/packages/standalone/releases/0.147.0-x86_64-unknown-linux-musl, bin /home/nick/.codex/packages/standalone/releases/0.147.0-x86_64-unknown-linux-musl/bin, resources /home/nick/.codex/packages/standalone/releases/0.147.0-x86_64-unknown-linux-musl/codex-resources, path /home/nick/.codex/packages/standalone/releases/0.147.0-x86_64-unknown-linux-musl/codex-path)\", \"managed by bun\": \"false\", \"managed by npm\": \"false\", \"managed by pnpm\": \"false\", \"managed package root\": \"not set\" }, \"remediation\": null, \"durationMs\": 2 }, \"mcp.config\": { \"id\": \"mcp.config\", \"category\": \"mcp\", \"status\": \"ok\", \"summary\": \"MCP configuration is locally consistent\", \"details\": { \"configured servers\": \"1\", \"disabled servers\": \"0\", \"streamable_http servers\": \"1\" }, \"remediation\": null, \"durationMs\": 132 }, \"network.env\": { \"id\": \"network.env\", \"category\": \"network\", \"status\": \"ok\", \"summary\": \"network-related environment looks readable\", \"details\": { \"proxy env vars\": \"none\" }, \"remediation\": null, \"durationMs\": 0 }, \"network.provider_reachability\": { \"id\": \"network.provider_reachability\", \"category\": \"reachability\", \"status\": \"ok\", \"summary\": \"active provider endpoints are reachable over HTTP\", \"details\": { \"ChatGPT base URL\": \"https://chatgpt.com/backend-api/ reachable (HTTP 404)\", \"reachability mode\": \"ChatGPT auth\" }, \"remediation\": null, \"durationMs\": 156 }, \"network.websocket_reachability\": { \"id\": \"network.websocket_reachability\", \"category\": \"websocket\", \"status\": \"ok\", \"summary\": \"Responses WebSocket handshake succeeded\", \"details\": { \"DNS\": \"2 IPv4, 2 IPv6, first IPv6\", \"auth mode\": \"chatgpt\", \"connect timeout\": \"15000 ms\", \"endpoint\": \"wss://chatgpt.com/backend-api/\", \"handshake result\": \"HTTP 101 Switching Protocols\", \"model provider\": \"openai\", \"models etag present\": \"true\", \"provider name\": \"OpenAI\", \"proxy env vars\": \"none\", \"reasoning header\": \"false\", \"server model present\": \"false\", \"supports websockets\": \"true\", \"wire API\": \"responses\" }, \"remediation\": null, \"durationMs\": 571 }, \"runtime.provenance\": { \"id\": \"runtime.provenance\", \"category\": \"runtime\", \"status\": \"ok\", \"summary\": \"running standalone on linux-x86_64\", \"details\": { \"commit\": \"unknown\", \"current executable\": \"/home/nick/.codex/packages/standalone/releases/0.147.0-x86_64-unknown-linux-musl/bin/codex\", \"install method\": \"standalone (unix, package /home/nick/.codex/packages/standalone/releases/0.147.0-x86_64-unknown-linux-musl, bin /home/nick/.codex/packages/standalone/releases/0.147.0-x86_64-unknown-linux-musl/bin, resources /home/nick/.codex/packages/standalone/releases/0.147.0-x86_64-unknown-linux-musl/codex-resources, path /home/nick/.codex/packages/standalone/releases/0.147.0-x86_64-unknown-linux-musl/codex-path)\", \"platform\": \"linux-x86_64\", \"version\": \"0.147.0\" }, \"remediation\": null, \"durationMs\": 0 }, \"runtime.search\": { \"id\": \"runtime.search\", \"category\": \"search\", \"status\": \"ok\", \"summary\": \"search is OK (bundled)\", \"details\": { \"search command\": \"/home/nick/.codex/packages/standalone/releases/0.147.0-x86_64-unknown-linux-musl/codex-path/rg\", \"search command readiness\": \"file exists\", \"search provider\": \"bundled\" }, \"remediation\": null, \"durationMs\": 0 }, \"sandbox.helpers\": { \"id\": \"sandbox.helpers\", \"category\": \"sandbox\", \"status\": \"ok\", \"summary\": \"sandbox configuration is readable\", \"details\": { \"approval policy\": \"OnRequest\", \"codex-linux-sandbox helper\": \"/home/nick/.codex/tmp/arg0/codex-arg0uniuIC/codex-linux-sandbox\", \"execve wrapper helper\": \"/home/nick/.codex/tmp/arg0/codex-arg0uniuIC/codex-execve-wrapper\", \"filesystem sandbox\": \"restricted\", \"network sandbox\": \"restricted\" }, \"remediation\": null, \"durationMs\": 0 }, \"state.paths\": { \"id\": \"state.paths\", \"category\": \"state\", \"status\": \"ok\", \"summary\": \"state paths and databases are inspectable\", \"details\": { \"CODEX_HOME\": \"/home/nick/.codex (dir)\", \"active rollout files\": \"926 files, 1731341680 total bytes, 1869699 average bytes\", \"archived rollout files\": \"11 files, 4198984 total bytes, 381725 average bytes\", \"goals DB\": \"/home/nick/.codex/goals_1.sqlite (file)\", \"goals DB integrity\": \"ok\", \"log DB\": \"/home/nick/.codex/logs_2.sqlite (file)\", \"log DB integrity\": \"ok\", \"log dir\": \"/home/nick/.codex/log (dir)\", \"memories DB\": \"/home/nick/.codex/memories_1.sqlite (file)\", \"memories DB integrity\": \"ok\", \"queue DB\": \"/home/nick/.codex/queue_1.sqlite (file)\", \"queue DB integrity\": \"ok\", \"sqlite home\": \"/home/nick/.codex (dir)\", \"standalone release cache\": \"24 entries in /home/nick/.codex/packages/standalone/releases\", \"state DB\": \"/home/nick/.codex/state_5.sqlite (file)\", \"state DB integrity\": \"ok\", \"thread history DB\": \"/home/nick/.codex/thread_history_1.sqlite (file)\", \"thread history DB integrity\": \"ok\" }, \"remediation\": null, \"durationMs\": 552 }, \"state.rollout_db_parity\": { \"id\": \"state.rollout_db_parity\", \"category\": \"threads\", \"status\": \"warning\", \"summary\": \"rollout files and state DB thread inventory differ\", \"details\": { \"default model provider\": \"openai\", \"rollout DB active files\": \"926\", \"rollout DB active rows\": \"924\", \"rollout DB archive mismatches\": \"0\", \"rollout DB archived files\": \"11\", \"rollout DB archived rows\": \"11\", \"rollout DB duplicate DB paths\": \"0\", \"rollout DB duplicate rollout thread ids\": \"0\", \"rollout DB malformed file names\": \"0\", \"rollout DB missing active rows\": \"2\", \"rollout DB missing active sample\": [ \"/home/nick/.codex/sessions/2026/03/17/rollout-2026-03-17T17-07-50-019cfe45-2773-7d11-8d6c-66388c9d8828.jsonl\", \"/home/nick/.codex/sessions/2026/03/17/rollout-2026-03-17T17-13-28-019cfe4a-4efa-7792-a2d7-ad5df5e50d9b.jsonl\" ], \"rollout DB missing archived rows\": \"0\", \"rollout DB model providers\": \"openai=935\", \"rollout DB rows\": \"935\", \"rollout DB scan cap reached\": \"false\", \"rollout DB scan errors\": \"0\", \"rollout DB sources\": \"cli=359, vscode=291, subagent:thread_spawn=209, exec=44, subagent:review=32\", \"rollout DB stale rows\": \"0\" }, \"issues\": [ { \"severity\": \"warning\", \"cause\": \"rollout files are missing from the state DB\", \"measured\": \"2 active, 0 archived\", \"expected\": \"every rollout file has a matching threads row\", \"remedy\": null, \"fields\": [] } ], \"remediation\": null, \"durationMs\": 156 }, \"system.environment\": { \"id\": \"system.environment\", \"category\": \"system\", \"status\": \"ok\", \"summary\": \"OS language en-US\", \"details\": { \"EDITOR\": \"not set\", \"LANG\": \"en_US.UTF-8\", \"VISUAL\": \"not set\", \"os\": \"Pop!_OS 24.4.0 (noble) [64-bit]\", \"os language\": \"en-US\", \"os type\": \"Pop!_OS\", \"os version\": \"24.4.0\" }, \"remediation\": null, \"durationMs\": 16 }, \"terminal.env\": { \"id\": \"terminal.env\", \"category\": \"terminal\", \"status\": \"ok\", \"summary\": \"terminal metadata was detected\", \"details\": { \"COLORTERM\": \"truecolor\", \"DISPLAY\": \"present\", \"TERM\": \"xterm-256color\", \"WAYLAND_DISPLAY\": \"present\", \"color output\": \"enabled\", \"effective locale\": \"en_US.UTF-8\", \"stderr is terminal\": \"true\", \"stdin is terminal\": \"true\", \"stdout is terminal\": \"true\", \"terminal\": \"unknown\", \"terminal size\": \"81x61\" }, \"remediation\": null, \"durationMs\": 0 }, \"terminal.title\": { \"id\": \"terminal.title\", \"category\": \"title\", \"status\": \"ok\", \"summary\": \"terminal title default\", \"details\": { \"terminal title activity\": \"true\", \"terminal title items\": \"activity, project-name\", \"terminal title project source\": \"git repo root\", \"terminal title project value\": \"read\", \"terminal title source\": \"default\" }, \"remediation\": null, \"durationMs\": 0 }, \"updates.status\": { \"id\": \"updates.status\", \"category\": \"updates\", \"status\": \"ok\", \"summary\": \"update configuration is locally consistent\", \"details\": { \"cached latest version\": \"0.147.0\", \"check for update on startup\": \"true\", \"last checked at\": \"2026-08-07T16:48:03.252075601Z\", \"latest version\": \"0.147.0\", \"latest version status\": \"current version is not older\", \"update action\": \"standalone installer\", \"version cache\": \"/home/nick/.codex/version.json\" }, \"remediation\": null, \"durationMs\": 333 } } } ``` ### What issue are you seeing? Codex cli renders session properly. Android ChatGPT remote app renders only first prompt + a thinking & tool call cell: \"Image\" ### What steps can reproduce the bug? Uploaded thread: 019fdd41-5661-7292-a605-a712215681d5 ### What is the expected behavior? _No response_ ### Additional information _No response_", "url": "https://github.com/openai/codex/issues/37598", "createdAt": "2026-08-08T14:56:55Z", "updatedAt": "2026-08-12T19:50:37Z", "timestamp": "2026-08-12T19:50:37Z", "metrics": { "reactions": 1, "comments": 3 }, "labels": [ "bug", "session", "remote" ], "author": "nick1udwig", "state": "open", "assignees": [] }, { "id": "github:openai/codex:issue:37620", "source": "github", "group": "coding-agent-infrastructure", "project": "openai/codex", "kind": "issue", "title": "[macOS/iOS Remote] Persisted mobile turns are omitted from the next Desktop model context in the same thread", "text": "### What version of the Codex App are you using (From “About Codex” dialog)? 26.803.41515 (build 6321) ### What subscription do you have? ChatGPT Pro ### What platform is your computer? `Darwin 25.4.0 arm64 arm` (macOS 26.4.1) ### What issue are you seeing? Turns sent from ChatGPT iOS Remote were persisted in the canonical Codex thread and visible in the task history, but they were omitted from the context supplied to a later Desktop model run in that same thread. This was not a missing-message UI issue: - `list_threads` showed exactly one task, not a fork or duplicate. - `read_thread` for that task contained the iOS turns, their image attachment, and the assistant replies in the correct order. - The later Desktop model input did not contain those turns and answered as if they had never happened. - After being asked explicitly, the Desktop agent used `read_thread`, found the omitted turns, and recovered the missing context. The durable thread and model-visible context therefore diverged. ### What steps can reproduce the bug? 1. Start a long-running Codex task in the macOS app. In this case the task ran for several hours and had at least one recorded context compaction. 2. Open the same active task from ChatGPT iOS Remote. 3. Send a follow-up from iOS and receive a completed assistant response. 4. Send another iOS follow-up with an image attachment, receive a response, then send one more text follow-up. 5. Later, continue the same task from Codex Desktop. 6. Ask the Desktop agent about the iOS messages. 7. Observe that the agent's supplied context does not include them. 8. Inspect the canonical task with `read_thread`: the iOS turns and responses are present in the same thread and ordered before the Desktop continuation. Observed on 2026-08-08. The iOS turns completed around 19:25–19:34 CEST; a later Desktop continuation around 22:19 CEST received stale/incomplete context. The private thread/session ID and a screenshot are available to OpenAI staff through a private channel if needed. They are omitted here because the conversation contains private project data. ### What is the expected behavior? Every new model run should build its context from the latest canonical history of the selected thread, regardless of whether prior turns were created from iOS Remote or Desktop. If cross-device reconciliation cannot guarantee this, Desktop should block the continuation or warn that its context is stale. It should never silently run from a history snapshot that omits already-persisted turns. ### Additional information - Codex CLI bundled with the app: `0.147.0-alpha.6.5` - Model: `gpt-5.6-sol` - The macOS UI and the canonical `read_thread` result eventually agreed; only the model-visible input was stale. - The thread had undergone context compaction, so stale checkpoint/compaction reconciliation may be involved. This is an inference, not a confirmed root cause. - Related but distinct: #21743 covers an open Desktop view not refreshing after another app-server client appends a turn. Here the turns were present in the canonical/UI history but absent from the subsequent model context. - Related but distinct: #29094 covers mobile/SSH turns not live-syncing into Desktop. This case used the supported ChatGPT iOS Remote flow and demonstrated durable-history versus model-input divergence.", "url": "https://github.com/openai/codex/issues/37620", "createdAt": "2026-08-08T20:42:02Z", "updatedAt": "2026-08-12T19:50:50Z", "timestamp": "2026-08-12T19:50:50Z", "metrics": { "reactions": 0, "comments": 4 }, "labels": [ "bug", "context", "app", "session", "remote" ], "author": "Devby", "state": "open", "assignees": [] }, { "id": "github:openai/codex:issue:37658", "source": "github", "group": "coding-agent-infrastructure", "project": "openai/codex", "kind": "issue", "title": "[Windows 10 / 26.803] Codex Micro service causes Logitech wireless mouse stutter; full no-device service stub resolves it", "text": "### Summary On Windows 10, Codex Desktop caused severe system-wide stuttering when using a Logitech mouse through its wireless USB receiver. The same mouse worked normally over a wired connection. Disabling only the HID topology watcher did **not** resolve the symptom. Replacing the complete optional Codex Micro service module with an API-compatible no-device stub did resolve it. This is a controlled diagnostic A/B result on a copied runtime. The signed Microsoft Store installation was not modified. Related reports: #34327 and #33912. ### Environment - Microsoft Store package: `OpenAI.Codex 26.803.5235.0`, x64 - Internal desktop app version: `26.803.41515` - Windows 10 Pro 22H2, build `19045` - Mouse: Logitech wireless HID mouse - Receiver: USB `VID_046D / PID_C54D` - Exact retail mouse model: not exposed by Windows and therefore not guessed Only the generic VID/PID is included. Device serial numbers, complete PnP instance IDs, usernames, account information, local paths, task IDs, configuration, conversations, and raw logs are intentionally omitted. ### Symptoms With Codex Desktop running and the mouse connected wirelessly: - pointer movement became severely jerky across Windows; - clicks and movement intermittently stalled; - Windows occasionally displayed “USB device not recognized”; - recovery sometimes required unplugging and reconnecting the Logitech receiver. Using the same mouse through a wired connection did not reproduce the problem. ### First diagnostic patch: disabling only `CodexMicroService.start()` The current service chunk was: ```text resources/app.asar -> .vite/build/service-CJETEjOt.js ``` The first copied-runtime experiment used a same-length UTF-8/ASCII replacement. Original sequence: ```js start(){if(this.lifecycleState!==`started`){this.lifecycleState=`started` ``` Replacement: ```js start(){if(false ){this.lifecycleState=`started` ``` The bytes following `false` were padded with ASCII space bytes (`0x20`) so the service entry size and all later ASAR offsets remained unchanged. This prevented the service from starting the native HID topology watcher. Runtime inspection confirmed that `hid-topology-watcher.node` and `HID.DLL` were no longer mapped. However, the service module was still evaluated at the top level. It still resolved the Work Louder dependency graph and loaded the serialport native binding: ```text @worklouder/device-kit-oai -> @worklouder/wl-device-kit -> serialport -> @serialport/bindings-cpp/.../bindings.node ``` The severe wireless-mouse stutter remained. Disabling only `start()` was therefore insufficient on this build. ### Effective diagnostic patch: replacing the entire service module The original service entry was `24,101` bytes and exported only `CodexMicroService`. I replaced the complete entry with the following CommonJS module: ```js \"use strict\"; const noDeviceState = Object.freeze({ status: \"not-detected\", transport: null, model: null, error: null, battery: null }); class CodexMicroService { constructor(options = {}) { this.options = options; this.deviceState = noDeviceState; } getState() { return this.deviceState; } start() {} async updateLighting() { return false; } async stop() {} dispose() { return this.stop(); } } exports.CodexMicroService = CodexMicroService; ``` The remaining bytes through the original `24,101`-byte entry boundary were filled with ASCII `0x20` bytes. This preserved the entry size and every subsequent ASAR file offset. The replacement retains the API used by `CodexMicroServiceManager`: - constructor accepting the callback/options object; - `getState()`; - `start()`; - `updateLighting()`; - `stop()`; - `dispose()`. It always reports the normal no-device state and performs no hardware or lighting work. ### ASAR integrity update The patcher parses the ASAR header and identifies the service by content markers instead of relying only on the generated filename. Required markers include: - `@worklouder/device-kit-oai`; - `@worklouder/wl-device-kit`; - `exports.CodexMicroService=`; - the expected `getState`, `updateLighting`, `stop`, and `dispose` methods. It refuses to patch unless exactly one matching entry is found and all API markers match. For this build: - original service SHA-256: `506eb3058a2ce87f436dfb191df2ac3d4b675117281790209049a09c3ca98103` - patched service SHA-256: `a59101ef591b4a4e5a6f27ecd9ec7b0187f108e77da7887a1794a939dee222a7` Both the entry's `integrity.hash` and its single `integrity.blocks[0]` value were replaced with the patched SHA-256. The ASAR header length was unchanged. The patch is version/hash pinned. After an application update it rebuilds from the new Store package and aborts rather than guessing if the module layout or API contract changed. ### Validation Static and behavioral validation confirmed that the patched service entry: - contains no `@worklouder` reference; - contains no `hid-topology-watcher` reference; - contains no `serialport` reference; - exports the expected `CodexMicroService` class; - passes JavaScript syntax validation; - passes calls to `getState`, `start`, `updateLighting`, `stop`, and `dispose`; - matches the updated ASAR entry and block-integrity hashes. After launching the full-service-stubbed copy, the severe wireless mouse stuttering stopped. ### Interpretation On this system, removing only the HID topology watcher was not enough. The difference between the two copied-runtime tests indicates that the complete optional Codex Micro / Work Louder module-loading path must remain inactive when no supported device is being used. The “USB device not recognized” symptom is reported as an observation; I am not claiming that Codex permanently damaged or reconfigured the receiver. ### Requested product fix Please provide a supported setting that disables Codex Micro before loading any Work Louder HID or serial native dependency. When no compatible device is present or the feature is unused, the service should return a stable `not-detected` state without evaluating: - `@worklouder/device-kit-oai`; - `@worklouder/wl-device-kit`; - `node-hid` / `HID.node`; - `serialport` / `bindings.node`; - the HID topology watcher. Optional hardware integration should also remain isolated from the Electron main process and fail closed after native loading or discovery errors. This byte-level replacement is an unsupported diagnostic experiment, not a recommended end-user workaround.", "url": "https://github.com/openai/codex/issues/37658", "createdAt": "2026-08-09T03:28:49Z", "updatedAt": "2026-08-13T17:23:43Z", "timestamp": "2026-08-13T17:23:43Z", "metrics": { "reactions": 0, "comments": 1 }, "labels": [ "bug", "windows-os", "app", "performance" ], "author": "yinyin333333", "state": "open", "assignees": [] }, { "id": "github:openai/codex:issue:37673", "source": "github", "group": "coding-agent-infrastructure", "project": "openai/codex", "kind": "issue", "title": "migrate-rollouts silently drops >16 MiB JSONL records while reporting migration successful", "text": "### What version of Codex CLI is running? `0.148.0-alpha.5` ### What subscription do you have? Not applicable (local rollout migration). ### Which model were you using? Not applicable (local rollout migration). ### What platform is your computer? macOS / Darwin 27.0.0 / arm64 ### What terminal are you using? zsh ### Codex doctor report Not included: this is a deterministic local storage transformation and source-level reproduction with no auth, network, or model dependency. ### What is the issue? `codex migrate-rollouts --apply` can silently omit valid legacy JSONL records larger than 16 MiB while reporting the thread as successfully migrated. The current implementation sets: ```rust const MAX_ROLLOUT_LINE_BYTES: usize = 16 * 1024 * 1024; ``` When a record is larger than that limit, `read_rollout_record()` consumes and discards the whole record through its newline and returns no line to the canonicalizer. The record is therefore absent from the staged paginated rollout and is not recoverable from the SQLite projection. Migration can still finish with `status = migrated` and no warning or message. The size check happens before JSON parsing and is not restricted to tool output records, so it also affects valid `compacted` checkpoints. Dry-run does not detect this. For a legacy rollout it reads session metadata and returns `eligible` without scanning all records, so the first full-record scan and oversized-record handling occur only during `--apply`. The existing migration test also demonstrates the behavior: a valid oversized `function_call_output` is absent after migration while the outcome remains migrated. ### Steps to reproduce 1. Create a valid legacy rollout JSONL containing normal session metadata and normal events. 2. Add a syntactically valid JSONL record larger than 16 MiB, for example: - a `response_item` / `custom_tool_call_output` containing inline image data; or - a `compacted` record whose `replacement_history` exceeds 16 MiB. 3. Add another valid event after the oversized record to show that processing continues. 4. Run a dry-run: ```shell codex migrate-rollouts --thread --json ``` The rollout is reported as eligible; the oversized record is not reported. 5. Back up the test rollout, then run: ```shell codex migrate-rollouts --apply --thread --json ``` 6. Compare the migrated rollout with the input. ### What did you expect to happen? Migration should never silently turn a valid rollout into a partial rollout. Preferably, migration should preserve valid records losslessly. If a finite per-record limit is required, then: - dry-run should scan for and report oversized records; - apply should fail closed before replacing the source, or require an explicit opt-in to omit data; - any partial result should not use the unqualified `migrated` status; - output should report skipped record counts, sizes, and positions; - a recoverable backup should exist before source replacement. ### What happened instead? - The oversized record is consumed through its newline but not passed to canonicalization. - Migration continues with later records. - The staged file replaces the original rollout without the oversized record. - The outcome can be `migrated` with `message = null`. - There is no skipped-record count, byte count, ordinal, sentinel, or warning. - Surviving records are assigned canonical ordinals, so there is no ordinal gap to reveal the loss. - Dry-run reports `eligible` because it does not perform the full scan. For a dropped `custom_tool_call_output`, resume may only synthesize an `aborted` output if the corresponding call remains; the actual output is not restored. For a dropped `compacted { replacement_history }` record, resume may replay surviving raw events, but that is not necessarily equivalent to the compacted model-visible history and its checkpoint/baseline state. A newer surviving checkpoint can reduce runtime impact, but it does not restore archival fidelity. ### Additional information I performed a read-only, content-safe metadata audit of three existing legacy rollouts. I did **not** run `--apply` on them. Across those three files, there were: - 10 syntactically valid records larger than 16 MiB; - 242,416,165 total bytes in those records (about 231 MiB); - 7 `response_item / custom_tool_call_output` records dominated by inline image data; - 3 `compacted / replacement_history` records dominated by image-bearing history. This shows the limit is reachable in real Codex sessions, not only with artificial terminal output. No session payloads, inline images, thread IDs, workspace paths, or credentials are included in this report. Relevant implementation and tests: - CLI migration/reporting: https://github.com/openai/codex/pull/37348 - Oversized-record handling: https://github.com/openai/codex/pull/37191 - Current implementation: https://github.com/openai/codex/blob/main/codex-rs/thread-store/src/local/rollout_migration.rs - Current tests: https://github.com/openai/codex/blob/main/codex-rs/thread-store/src/local/rollout_migration_tests.rs Related but distinct reports: - https://github.com/openai/codex/issues/37670 — migration fidelity issue involving duplicated compatibility input, not silent oversized-record loss - https://github.com/openai/codex/issues/28531 — image-heavy inline rollout data causing Desktop crashes/freezes - https://github.com/openai/codex/issues/33735 — `compacted.replacement_history` duplicating inline images and growing rollout size Suggested regression coverage: - >16 MiB `custom_tool_call_output`; - >16 MiB `compacted / replacement_history`; - a valid record after the oversized record; - dry-run/apply consistency; - resume/readback fidelity; - explicit non-success status whenever any record is omitted.", "url": "https://github.com/openai/codex/issues/37673", "createdAt": "2026-08-09T06:58:32Z", "updatedAt": "2026-08-12T14:08:15Z", "timestamp": "2026-08-12T14:08:15Z", "metrics": { "reactions": 0, "comments": 2 }, "labels": [ "bug", "CLI", "session" ], "author": "Yasei-no-otoko", "state": "open", "assignees": [], "change": "updated" }, { "id": "github:openai/codex:issue:37686", "source": "github", "group": "coding-agent-infrastructure", "project": "openai/codex", "kind": "issue", "title": "Consistent 5-second delay when opening historical tasks after Computer Use is started", "text": "### What version of the Codex App are you using (From “About Codex” dialog)? - Codex desktop version: 26.803.41515 - Computer Use service version: 26.804.1000633 ### What subscription do you have? pro 20x ### What platform is your computer? macOS 26.6 ### What issue are you seeing? Environment: - macOS - Codex desktop version: 26.803.41515 - Computer Use service version: 26.804.1000633 I am seeing a reproducible, fixed 5-second delay when opening a historical task for the first time in the current app session. The issue appears to be related to SkyComputerUseService: 1. Launch Codex and invoke Computer Use once. 2. SkyComputerUseService starts and connects to Codex. 3. Open any historical task that has not yet been opened during the current app session. 4. The task consistently pauses for exactly 5 seconds before loading. 5. Other historical tasks also experience the same 5-second delay on their first open. Manually running the following command immediately removes the delay: /usr/bin/killall SkyComputerUseService After terminating SkyComputerUseService, historical tasks load normally. However, invoking Computer Use once causes the service to restart, and the fixed 5-second delay returns for other historical tasks that have not yet been opened. The logs show: - maybe_resume_started - Exactly 5 seconds later: maybe_resume_owner_discovery_failed errorMessage=timeout - thread/read and thread/resume then complete within milliseconds Computer Use itself works normally, and its macOS Accessibility and Screen Recording permissions are available. This suggests that SkyComputerUseService may be registered as an IPC client but does not respond correctly or promptly to the thread owner discovery/client discovery request. Unknown or unsupported discovery requests should return immediately instead of waiting for the 5-second timeout. Expected behavior: Starting or using Computer Use should not delay the first opening of unrelated historical tasks. Current workaround: Terminate SkyComputerUseService after using Computer Use, but this makes Computer Use unavailable until it is invoked and restarted again. ### What steps can reproduce the bug? Environment: - macOS - Codex desktop version: 26.803.41515 - Computer Use service version: 26.804.1000633 I am seeing a reproducible, fixed 5-second delay when opening a historical task for the first time in the current app session. The issue appears to be related to SkyComputerUseService: 1. Launch Codex and invoke Computer Use once. 2. SkyComputerUseService starts and connects to Codex. 3. Open any historical task that has not yet been opened during the current app session. 4. The task consistently pauses for exactly 5 seconds before loading. 5. Other historical tasks also experience the same 5-second delay on their first open. Manually running the following command immediately removes the delay: /usr/bin/killall SkyComputerUseService After terminating SkyComputerUseService, historical tasks load normally. However, invoking Computer Use once causes the service to restart, and the fixed 5-second delay returns for other historical tasks that have not yet been opened. The logs show: - maybe_resume_started - Exactly 5 seconds later: maybe_resume_owner_discovery_failed errorMessage=timeout - thread/read and thread/resume then complete within milliseconds Computer Use itself works normally, and its macOS Accessibility and Screen Recording permissions are available. This suggests that SkyComputerUseService may be registered as an IPC client but does not respond correctly or promptly to the thread owner discovery/client discovery request. Unknown or unsupported discovery requests should return immediately instead of waiting for the 5-second timeout. Expected behavior: Starting or using Computer Use should not delay the first opening of unrelated historical tasks. Current workaround: Terminate SkyComputerUseService after using Computer Use, but this makes Computer Use unavailable until it is invoked and restarted again. ### What is the expected behavior? _No response_ ### Additional information _No response_", "url": "https://github.com/openai/codex/issues/37686", "createdAt": "2026-08-09T10:13:08Z", "updatedAt": "2026-08-13T17:16:22Z", "timestamp": "2026-08-13T17:16:22Z", "metrics": { "reactions": 1, "comments": 6 }, "labels": [ "bug", "app", "app-server", "computer-use", "performance" ], "author": "zhangzhenguo-it", "state": "open", "assignees": [] }, { "id": "github:openai/codex:issue:37695", "source": "github", "group": "coding-agent-infrastructure", "project": "openai/codex", "kind": "issue", "title": "Codex Desktop: declared owner-auth and secret-manager capabilities are absent at runtime", "text": "### Product / environment - Codex Desktop on Windows - External browser automation routed to a separately managed Linux browser host - A custom runtime plugin declares owner-authentication assistance and host-local secret-manager policies ### Issue A task explicitly authorized use of host-local credential stores (Google Secret Manager / Google Password Manager) for a logged-in external website. The active Codex session exposed neither a scoped credential-consumption tool nor the declared `owner_assistance_*` tools. The live tool inventory also had no session-bound SMS authentication tool. Because capability availability is discovered only after work begins, Codex repeatedly falls back to short owner-login windows. The windows expire, and the external task cannot progress even though the user selected approved host-local credential stores. ### Reproduction 1. Start Codex Desktop with a plugin whose skill/policy declares owner-authentication assistance. 2. Ask Codex to complete a logged-in external web workflow using a host-local secret/password manager. 3. Inspect the active tool inventory. 4. Observe that `owner_assistance_status/open/pause/resolve` and any scoped password-manager credential consumer are absent. 5. Codex can launch a bounded login window but cannot consume the user-selected credential store or deliver the declared owner-assistance incident, causing repeated expiration loops. ### Actual behavior - Declared authentication-assistance tools are absent from the live session. - No safe API exists for selecting a credential by opaque reference and consuming it directly into the approved browser session. - The limitation is surfaced late, after browser work and repeated owner handoffs. - The user cannot distinguish an intentional security boundary from missing runtime capabilities. ### Expected behavior At least one of the following should be guaranteed: 1. A scoped, auditable credential-consumption interface that accepts only an opaque secret reference, keeps the value host-local/in-memory, and binds use to one approved browser field/session without exposing the secret to the model, logs, chat, or tool arguments; or 2. A deterministic preflight that reports before browser launch that credential-store consumption is unavailable; and 3. Runtime enforcement that a skill cannot advertise `owner_assistance_*` tools unless those exact tools are live and callable in the current session. The product should continue to prohibit raw passwords in chat and should not weaken CAPTCHA or account-security boundaries. ### Privacy No credentials, account identifiers, external case details, screenshots, cookies, or session data are included in this report.", "url": "https://github.com/openai/codex/issues/37695", "createdAt": "2026-08-09T12:13:15Z", "updatedAt": "2026-08-13T16:02:09Z", "timestamp": "2026-08-13T16:02:09Z", "metrics": { "reactions": 0, "comments": 5 }, "labels": [ "bug", "windows-os", "auth", "app", "skills", "browser" ], "author": "jyongchul", "state": "open", "assignees": [] }, { "id": "github:openai/codex:issue:37725", "source": "github", "group": "coding-agent-infrastructure", "project": "openai/codex", "kind": "issue", "title": "macOS arm64 0.147.0 canonical release binary fails strict codesign verification", "text": "The canonical Apple Silicon Codex CLI executable published in `rust-v0.147.0` fails strict Apple code-signature verification. I independently verified both distribution paths: - canonical GitHub release asset `codex-package-aarch64-apple-darwin.tar.gz` - npm `@openai/codex@0.147.0-darwin-arm64` The GitHub archive SHA-256 matches both GitHub release metadata and `codex-package_SHA256SUMS`. The extracted standalone executable and npm executable are byte-for-byte identical (`cmp` exit 0). Native executable SHA-256: `19c4f144c5226a9f17c58e6f0fa854843b0f77a6eb420f40e2745a12f10f5d37` Architecture: `Mach-O 64-bit executable arm64` Embedded signing metadata is parseable and reports: `Identifier=codex` `TeamIdentifier=2DC432GLL2` However: `codesign --verify --strict --verbose=4 ` returns: `invalid signature (code or signature have been modified)` `In architecture: arm64` Entitlements inspection also reports: `warning: binary contains an invalid entitlements blob.` `spctl --assess --type execute --verbose=4` returns: `internal error in Code Signing subsystem` This occurs on the exact checksum-verified canonical release bytes, not on a modified or repackaged executable. This appears particularly relevant because the 0.147.0 release notes include PR #37154, “Use Azure Key Vault for macOS notarization.” Could OpenAI confirm whether the above SHA-256 is the intended Apple Silicon 0.147.0 executable and whether it is expected to pass strict `codesign` verification? If this is a release-signing/notarization regression, is a corrected artifact planned? I can provide the complete release metadata, hashes, codesign output, archive inventory, and npm-versus-standalone comparison if useful.", "url": "https://github.com/openai/codex/issues/37725", "createdAt": "2026-08-09T18:49:41Z", "updatedAt": "2026-08-13T15:07:13Z", "timestamp": "2026-08-13T15:07:13Z", "metrics": { "reactions": 0, "comments": 2 }, "labels": [ "bug", "CLI" ], "author": "JohnnyGreen420", "state": "open", "assignees": [] }, { "id": "github:openai/codex:issue:37729", "source": "github", "group": "coding-agent-infrastructure", "project": "openai/codex", "kind": "issue", "title": "Completed subagents appear active until their results are opened", "text": "### What version of the Codex App are you using? The exact Codex Desktop build was not available to the agent. Observed on 2026-08-09. ### What subscription do you have? Not relevant to the UI behavior. ### What platform is your computer? macOS 26.6.1 (25G76), arm64. ### What issue are you seeing? Completed subagents can remain presented in the parent task UI as if they are still active. In this case, the UI appeared to show three active subagents, while the runtime agent-status query reported that every child agent was `completed` and only the parent agent was `running`. Opening each completed subagent caused its apparent active indicator to disappear. This suggests that the indicator represents an unread completion/result, but visually communicates ongoing execution instead. This is confusing because users may reasonably conclude that agents are still consuming model time or other resources. ### What steps can reproduce the bug? 1. Start one or more subagents from a parent task. 2. Let the subagents finish. 3. Return to the parent task without opening the completed subagent results. 4. Observe that the UI still appears to present some subagents as active. 5. Verify through agent runtime status that those subagents are `completed`. 6. Open the completed subagents one by one. 7. Observe that their indicators disappear after being viewed. ### What is the expected behavior? The UI should clearly distinguish: - `Running`: the subagent is still executing. - `Completed — unread result`: execution has ended, but its result has not been opened. - `Completed — read`: execution has ended and its result has been viewed. A label such as “3 unread subagent results” would avoid implying that three agents are still running. ### Additional information No continued execution was actually observed. The issue is the mismatch between the visual state and the runtime state, which made it necessary to inspect the agent status explicitly to determine whether resources were still being consumed.", "url": "https://github.com/openai/codex/issues/37729", "createdAt": "2026-08-09T19:08:19Z", "updatedAt": "2026-08-13T17:51:23Z", "timestamp": "2026-08-13T17:51:23Z", "metrics": { "reactions": 2, "comments": 5 }, "labels": [ "bug", "app", "subagent" ], "author": "JoachimHollman", "state": "open", "assignees": [], "change": "new" }, { "id": "github:openai/codex:issue:37743", "source": "github", "group": "coding-agent-infrastructure", "project": "openai/codex", "kind": "issue", "title": "Windows Computer Use runtime blocked by EPERM, then helper fails EnumWindows", "text": "### What version of the Codex App are you using (From “About Codex” dialog)? 26.803.5235.0 ### What subscription do you have? Unknown / not shown in diagnostics ### What platform is your computer? Microsoft Windows NT 10.0.26200.0 x64 ### What issue are you seeing? Computer Use cannot initialize in the ChatGPT/Codex Windows desktop app. The initial failure is: ``` EPERM: operation not permitted, lstat 'C:\\Users\\\\AppData\\Local\\OpenAI\\Codex' ``` The Windows ACLs on that directory are healthy: the current user, Administrators, and SYSTEM have full control. The bundled `cua_node` runtime and `@oai/sky` package are present and their manifests are intact. After staging the installed `@oai/sky` package inside the permitted workspace to bypass the initial sandbox denial, the package loads, but its first lightweight call fails with: ``` EnumWindows failed: The system cannot find the path specified. (0x80070003) ``` Completely quitting and reopening the desktop app does not fix either failure. ### What steps can reproduce the bug? 1. Open the ChatGPT/Codex Windows desktop app and a local task. 2. Install/enable the bundled Computer Use plugin. 3. Ask Codex to use Computer Use. 4. The required initialization import of `@oai/sky` fails while resolving the bundled runtime with the EPERM/lstat error above. 5. Completely quit the app, ensure it is no longer running, reopen it, and retry. The same error occurs. 6. Verify `C:\\Users\\\\AppData\\Local\\OpenAI\\Codex` exists and that the current user has full control. The error persists. 7. When the installed package is staged in the task workspace so it can load without touching the denied runtime path, calling `sky.list_apps()` launches the helper but fails with the EnumWindows error above. ### What is the expected behavior? The bundled Computer Use runtime should be readable by the trusted helper, and `sky.list_apps()` should enumerate targetable Windows applications and windows. ### Additional information Installed app package: `OpenAI.Codex_26.803.5235.0_x64__2p2nqsd0c76g0` Computer Use plugin version: `26.803.41515` Bundled CUA Node runtime manifest reports Node `24.14.0`, runtime archive `cua-node-0.0.6-20260723162306-088049353ddc-windows-x64.zip`, and target `windows-x64`. No Windows ACLs or security settings were changed during diagnosis. Restarting the app did not help. Reinstallation was not attempted because related Windows runtime reports indicate that reinstall may preserve the local runtime directory and may not resolve sandbox/bridge failures.", "url": "https://github.com/openai/codex/issues/37743", "createdAt": "2026-08-09T23:13:59Z", "updatedAt": "2026-08-12T22:31:36Z", "timestamp": "2026-08-12T22:31:36Z", "metrics": { "reactions": 0, "comments": 3 }, "labels": [ "bug", "windows-os", "sandbox", "app", "computer-use" ], "author": "ximoosea", "state": "open", "assignees": [] }, { "id": "github:openai/codex:issue:37760", "source": "github", "group": "coding-agent-infrastructure", "project": "openai/codex", "kind": "issue", "title": "Subagents do not inherit Responses API client metadata from parent turns", "text": "### What issue are you seeing? When an app-server client supplies `responsesapiClientMetadata` on `turn/start`, the custom metadata is included in the parent turn's Responses API request, but it is dropped when Codex starts or continues a subagent. This affects both multi-agent paths: - V1 spawn/follow-up submissions do not carry the parent turn's client metadata. - V2 mailbox submissions carry parent-turn identity, but have no channel for client metadata. - Delegate/review/Guardian child-entry paths have the same gap. As a result, downstream proxies and telemetry can attribute the root request to the originating client, but nested Responses API requests lose that attribution. Active child follow-ups can also retain stale attribution instead of following the triggering parent turn. The reserved `thread_id` and `turn_id` fields should remain child-owned; the bug concerns inheriting the caller's custom metadata fields. ### What steps can reproduce the bug? 1. Start a Codex thread through app-server. 2. Call `turn/start` with non-empty `responsesapiClientMetadata`, for example: ```json { \"client_trace_id\": \"parent-turn-a\", \"thread_id\": \"spoofed-thread-id\", \"turn_id\": \"spoofed-turn-id\" } ``` 3. Have the parent invoke `spawn_agent`. 4. Inspect the parent and child outbound `/responses` requests, particularly the `x-codex-turn-metadata` header. 5. Repeat with Multi-Agent V1 and V2. 6. For V2, send a follow-up while the child is active using a new value such as `parent-turn-b`, then inspect the child's next Responses request. Actual behavior: - The parent request contains `client_trace_id`. - The child spawn/follow-up request does not inherit it, or an active child continues with stale metadata. - The missing propagation is independent of the child-owned reserved IDs. ### What is the expected behavior? - A child spawn should inherit the triggering parent turn's custom Responses API client metadata. - Active child follow-ups should use the metadata associated with the input batch that triggers the sample. - `thread_id` and `turn_id` must always be generated from the child thread/turn and must not be inherited or spoofable. - V2 mailbox aggregation should treat parent-turn ID and client metadata independently: - inherit each unambiguous value; - clear stale custom metadata when the contributing inputs disagree or do not provide a single value; - let explicit steer metadata win for the batch it accompanies. ### Root cause The metadata currently stops at the parent turn's `TurnMetadataState`: - the V1 spawn path submits child input without the parent metadata; - the V2 mailbox models parent-turn ID only; - child submission/delegate/review entry points have no shared parent-turn context carrying both values. This is why merely preserving `parent_turn_id` does not fix client attribution. ### Proposed fix I prepared a focused implementation that introduces a parent-turn context containing both the optional parent turn ID and filtered custom client metadata, then propagates it through: - V1 and V2 spawn/follow-up paths; - the V2 mailbox and active-turn update path; - delegate, review, and Guardian child entry points; - internal `Submission` plumbing. It also: - filters reserved `thread_id` / `turn_id` fields; - clears both provenance fields at the public `submit_with_id` boundary to prevent spoofing; - stores explicit steer metadata with its pending input batch so it is applied only when that batch is drained; - handles conflicting V2 mailbox contributors without retaining stale attribution. Prepared implementation: - Commit: https://github.com/hancao97/codex/commit/cdff1987266ba44c00e36e991d3fdb9997fb456a - Compare: https://github.com/openai/codex/compare/main...hancao97:codex:codex/inherit-subagent-client-metadata?expand=1 ### Validation completed - Responses API integration coverage for V1 and V2 subagent spawn. - Active V2 follow-up coverage with changed client metadata. - Queue aggregation, conflict-clearing, and explicit-steer precedence tests. - Public-submit anti-spoof and delegate propagation coverage. - `cargo check -p codex-core --tests --offline`. - Focused `codex-core` tests. - `just test -p codex-protocol -p codex-mcp-server`. - `just fix -p codex-core -p codex-protocol -p codex-mcp-server`. - `just fmt` and `cargo fmt --all -- --check`. I did not find an existing issue covering this exact metadata-propagation gap. If this approach aligns with the intended semantics, I would be happy to open the prepared PR with an invitation, per the repository's external contribution policy.", "url": "https://github.com/openai/codex/issues/37760", "createdAt": "2026-08-10T02:07:41Z", "updatedAt": "2026-08-13T01:56:33Z", "timestamp": "2026-08-13T01:56:33Z", "metrics": { "reactions": 0, "comments": 1 }, "labels": [ "bug", "subagent", "app-server" ], "author": "hancao97", "state": "open", "assignees": [] }, { "id": "github:openai/codex:issue:37768", "source": "github", "group": "coding-agent-infrastructure", "project": "openai/codex", "kind": "issue", "title": "Windows Desktop 26.803: config.toml is atomically truncated and existing project tasks disappear from the sidebar", "text": "### What version of the Codex App are you using? Microsoft Store package: `OpenAI.Codex_26.803.5235.0_x64` ### What platform is your computer? Windows 11 Enterprise LTSC, version 10.0.26100, x64. ### Summary During one incident, Codex Desktop rewrote `%USERPROFILE%\\.codex\\config.toml` from 17,845 bytes to 4,267 bytes, removing many unrelated settings. Existing local project tasks then appeared to be lost from the sidebar, although the session files, thread rows, project assignments, and conversation contents were still intact. This looks like two related state-reconciliation failures: 1. a config processor/layer writer replaced a complete valid config with a much smaller partial config; 2. the Desktop sidebar/catalog stopped surfacing active project tasks that remained healthy in the core database. No raw config, transcripts, databases, internal project names, task IDs, credentials, or proprietary logs are attached to this public report. ### Timeline (2026-08-10, UTC+8) - **10:05:53** — A valid edit added one MCP server section to the existing config. The successful diff was additive only; no unrelated field was removed. - **10:12:05–10:15:18** — `logs_2.sqlite` repeatedly recorded activity from: - `codex_app_server::request_processors::config_processor` - `codex_config::loader::layer_io` - **10:16:14** — `config.toml` was replaced/re-written in one operation and shrank from **17,845 bytes to 4,267 bytes**. Many unrelated settings disappeared. - Afterward, the selected local project remained registered, but the sidebar showed only the current task and omitted older active tasks. - A full app restart did not restore the missing tasks. - Restoring the config from a known-good backup survived a subsequent restart, but the sidebar task visibility problem remained. The logs available locally do not contain the OS-level writer PID, so attribution to a specific process cannot be proven. However, no shell command or agent tool call in the incident window deleted, moved, copied over, or reset the config/session/state files. ### Evidence that conversation data was not deleted Read-only diagnostics showed: - `PRAGMA quick_check` and `PRAGMA integrity_check` on `state_5.sqlite`: **ok** - 63 active session rollout files and 31 archived rollout files still existed globally. - The affected project had 23 thread rows in the core database. - Eight top-level task assignments for the project were still present (the current task plus seven older tasks). - At least six older top-level tasks were active/unarchived but absent from the normal sidebar. - The project assignment metadata was correct. - The project was registered and marked expanded. - The missing task IDs had no persisted deleted flag. - Direct thread reads returned the original turn history. - Direct navigation by task ID opened the supposedly missing task successfully. - Opening a missing task did **not** add it back to the ordinary list. - Pinning the same task made it immediately appear in the sidebar. Pinning the other missing tasks made all of them visible again. This strongly suggests a Desktop sidebar/catalog/index inconsistency, not transcript loss. ### Persisted sidebar state observation The persisted Desktop state contained: ```text mode=project chatSortMode=priority projectSortMode=priority projectExpanded=true ``` The user did **not** intentionally select Priority mode. This is reported only as an observed persisted state value, not as a user action or proven root cause. The official troubleshooting workaround to switch to **Chronological** did not explain why active assigned tasks were omitted from the project view, or why pinning forced them back into the list. ### Reproduction / diagnostic sequence The original failure is intermittent, but this sequence reproduces the visibility inconsistency on the affected profile: 1. Start Codex Desktop with an existing local project containing multiple active tasks. 2. Observe that only the current task is shown under the project. 3. Restart the application; the older active tasks remain missing. 4. Verify that the project and task assignments still exist in the core state database. 5. Read or navigate to a missing task by its ID; its history opens normally. 6. Return to the sidebar; the task is still absent from the ordinary list. 7. Pin the task through the supported app thread API. 8. The task appears immediately in the pinned list. For the config portion: 1. Start with a valid multi-section `config.toml`. 2. Apply a valid additive MCP-server edit. 3. Allow the running Desktop app to process/reload configuration. 4. In the affected incident, the config was later replaced with a much smaller partial file, dropping unrelated settings. ### Expected behavior - A valid additive config edit must preserve all unrelated settings. - Desktop config reconciliation must never replace a complete config with a partial serialization. - Active, unarchived tasks with valid rollout files and project assignments must remain visible and searchable. - Opening or restarting the app must not make existing project tasks appear deleted. - If the sidebar catalog diverges from the core database, Desktop should rebuild it automatically or provide a supported “Reindex local tasks” action. ### Actual behavior - A complete config was replaced by a 4,267-byte partial config. - Many settings disappeared at once. - Existing active project tasks vanished from the normal sidebar despite healthy database/session state. - Restarting did not restore them. - Direct reads/navigation worked, and pinning forced the tasks to reappear. ### Workaround used 1. Created an offline backup of the complete Codex home state. 2. Restored `config.toml` from a known-good backup and validated that the app could parse it. 3. Restarted Codex and verified the restored config was no longer truncated. 4. Temporarily pinned the missing active tasks so they became visible. 5. Unarchived one intentionally archived task only as part of user-requested recovery. No direct edits were made to the conversation contents. ### Related issues This appears related to, but adds a distinct correlated config-rewrite timeline and a pinning-based visibility test beyond: - #27178 — Windows config overwritten on restart - #34076 — project registrations/sidebar catalog diverge from core database - #29337 — Windows project/workspace chats missing from sidebar - #17540 — local threads missing from sidebar/search while still present on disk - #25463 — project threads disappear while JSONL remains readable ### Questions for maintainers 1. Can `config_processor` or `layer_io` serialize only the currently loaded layer and atomically replace the full user config? 2. Is there a supported ownership/merge contract for Desktop writes to `config.toml`? 3. Which database/catalog is authoritative for Desktop project task visibility? 4. Why does pinning a healthy but hidden task immediately make it visible? 5. Can Desktop detect catalog drift and rebuild from `state_5.sqlite` plus rollout files without requiring manual state edits? 6. What minimal redacted diagnostics would be most useful for a follow-up private feedback upload? Sanitized timestamped log excerpts and file metadata can be provided privately on request. Raw configs, databases, and transcripts are intentionally withheld because they may contain sensitive information.", "url": "https://github.com/openai/codex/issues/37768", "createdAt": "2026-08-10T02:57:59Z", "updatedAt": "2026-08-12T18:36:29Z", "timestamp": "2026-08-12T18:36:29Z", "metrics": { "reactions": 0, "comments": 2 }, "labels": [ "bug", "windows-os", "app", "session", "config" ], "author": "M1nt-Ch0c0", "state": "open", "assignees": [] }, { "id": "github:openai/codex:issue:37770", "source": "github", "group": "coding-agent-infrastructure", "project": "openai/codex", "kind": "issue", "title": "Codex search/grep tool processes run indefinitely with no timeout — orphaned rg floods network FS (Lustre/NFS)", "text": "## Bug Description Codex search/grep tools (launched by `codex app-server --listen unix://` in code_mode_host mode) can run **indefinitely** with **no timeout and no automatic kill** — orphaned `rg` processes keep burning CPU/network I/O for 1+ hours on large projects (observed 46 min and 87 min). On a cluster where the project lives on a **network filesystem (Lustre/NFS)**, each file read is a network round-trip, so an unbounded recursive search produces sustained high-frequency small reads (measured ~72 RPC/s of 1-page reads at the Lustre client) and floods the storage network. ## Steps to Reproduce 1. Run `codex app-server` (code_mode_host) against a large project tree on a network filesystem (e.g. Lustre). 2. Have the model issue a grep/search tool call (e.g. `rg -n -C 3 PATTERN .` or `rg -n \"a|b|c\" `). 3. **Without any explicit cancellation** (close the session, or the request originates from app-server without a `cancellation_token`), observe: - The `rg` process keeps running for many minutes/hours. - `ps` shows it orphaned under `codex app-server` (PID chain: `rg → codex app-server → sh → systemd`). - No `terminate`/cancel is ever issued. Observed on codex-cli **0.147.0**: - `rg -n \"济南|jinan|...\" /xcfhome/llyu/project/FBP_binder/prot_design2` ran **46 minutes** (started 09:40, still alive at 10:26) before eventually finishing. - `rg -n -C 3 LKQQLREYIRWEEAARNLLGLIE .` ran **87+ minutes** (still alive at time of writing). ## Expected Behavior - A server-side **hard timeout** on tool executions (search/grep/exec) — e.g. 60–120 s — after which the child process is killed automatically, even if no client cancellation arrives. - Or: app-server (long-lived daemon) should reap/track children it spawned and kill them when the originating request/session is gone. ## Actual Behavior - No timeout exists in the search/exec path. - Cancellation is **client-owned only**: - `codex-rs/app-server/src/request_processors/search.rs`: `cancellation_token` is optional — `None => Arc::new(AtomicBool::new(false))` means \"never cancel\". - `codex-rs/exec-server/src/server/handler.rs`: `terminate()` is a passthrough — it is only invoked if the client explicitly calls it. - `codex-rs/file-search/src/lib.rs`: the walker checks the cancel flag only every `CHECK_INTERVAL = 1024` entries. - When the requesting session dies/disconnects, nothing kills the spawned child — it orphans under the long-lived `codex app-server` process. ## Environment - OS: RHEL 8 (kernel 4.18), x86_64 - Codex CLI: 0.147.0 (npm global) - Filesystem: Lustre (network FS); also reproduces the general NFS-family slowness - Home dir on network storage (no local SSD for project data) ## Error Output No error — the processes simply **never exit**: ``` $ ps -eo pid,etime,time,args | grep 'rg -n' 1417145 zpzeng 01:26:58 00:04:40 rg -n -C 3 LKQQLREYIRWEEAARNLLGLIE|LKQQLREY . # ^ still running after 1h26m, parent = codex app-server (long-lived daemon) $ cat /proc/fs/lustre/osc/*/rpc_stats # client-side evidence of the small-read storm 1-page read RPCs: ~72/s sustained during the search ``` ## Additional Context - Workaround used: manual `kill` of orphaned rg processes + a watchdog cron that kills search processes exceeding N minutes. - Related code: `codex-rs/app-server/src/fuzzy_file_search.rs` (no timeout, cancel-only), `codex-rs/exec-server/src/server/handler.rs` (terminate is passthrough), `codex-rs/file-search/src/lib.rs` (cancel check every 1024 entries, `follow_links(true)`, `hidden(false)`). - The `follow_links(true)` + `hidden(false)` defaults also expand search scope on large trees (symlinked output dirs), compounding the problem.", "url": "https://github.com/openai/codex/issues/37770", "createdAt": "2026-08-10T03:05:38Z", "updatedAt": "2026-08-13T01:52:22Z", "timestamp": "2026-08-13T01:52:22Z", "metrics": { "reactions": 1, "comments": 2 }, "labels": [ "bug", "CLI", "app-server", "performance" ], "author": "Molaison", "state": "open", "assignees": [] }, { "id": "github:openai/codex:issue:37783", "source": "github", "group": "coding-agent-infrastructure", "project": "openai/codex", "kind": "issue", "title": "[ChatGPT Chronicle] System Skill Creator is deleted from shared system Skills", "text": "### Summary A ChatGPT Chronicle/background run deletes the canonical **system Skill Creator** from the shared Codex system-Skills installation. The Chronicle worker starts the bundled Codex runtime with `skills.bundled.enabled=false`. The resulting cleanup appears to remove the shared `$CODEX_HOME/skills/.system` directory instead of merely disabling bundled Skills for that worker. The system Skill Creator then becomes unavailable to unrelated, ordinary Codex tasks. This report concerns the canonical OpenAI-provided system Skill Creator—not a personal or copied substitute. This have been like that since codex app released months ago, this is unacceptable. ### Affected environment - ChatGPT Desktop: 26.803.41515 (build 6321) - Bundled Codex CLI: 0.147.0-alpha.6.5 - macOS: 26.6.1, Apple silicon ### Reproduction 1. Start ChatGPT Desktop and confirm the canonical system Skill Creator is present under `$CODEX_HOME/skills/.system/skill-creator`. 2. Enable Chronicle and allow a Chronicle background task to start. 3. Observe that the Chronicle worker invokes the bundled Codex runtime with `skills.bundled.enabled=false`. 4. Inspect the shared system-Skills installation after the worker starts. 5. Start an unrelated Codex task and attempt to use the system Skill Creator. ### Actual result - `$CODEX_HOME/skills/.system` is removed. - The canonical system Skill Creator disappears and cannot be discovered by later ordinary tasks. - The system OpenAI Docs Skill disappears in the same event, confirming that this is a shared system-directory mutation rather than a failure isolated to one Skill. - A fresh normal Codex startup can restore the bundled system Skills, but a later Chronicle run removes them again. - Turning Chronicle off prevents recurrence only after any already-running Chronicle worker exits. The deletion is also reproducible with a disposable `CODEX_HOME`, without user cleanup scripts or scheduled automations. ### Expected result `skills.bundled.enabled=false` should control availability only for that worker. It must not delete, overwrite, or mutate the shared canonical system-Skills installation. In particular, a Chronicle task must never uninstall the system Skill Creator used by other tasks. ### Related upstream work This may share the cleanup defect reported in #19265 and addressed by #36989, but the currently distributed ChatGPT Desktop build above still reproduces the Chronicle-specific Skill Creator failure. Please confirm: 1. which released ChatGPT Desktop/Codex build first contains the fix; 2. whether Chronicle workers are covered by that fix; and 3. whether a guard will prevent background tasks configured with bundled Skills disabled from mutating `$CODEX_HOME/skills/.system`.", "url": "https://github.com/openai/codex/issues/37783", "createdAt": "2026-08-10T05:18:00Z", "updatedAt": "2026-08-12T15:23:23Z", "timestamp": "2026-08-12T15:23:23Z", "metrics": { "reactions": 0, "comments": 2 }, "labels": [ "bug", "app", "skills", "automations" ], "author": "omarpinarecords", "state": "open", "assignees": [], "change": "updated" }, { "id": "github:openai/codex:issue:37849", "source": "github", "group": "coding-agent-infrastructure", "project": "openai/codex", "kind": "issue", "title": "Long ChatGPT Desktop responses jump upward while scrolling", "text": "### What version of the Codex App are you using (From “About Codex” dialog)? 26.721.41059 ### What subscription do you have? Free ### What platform is your computer? Darwin 25.5.0 arm64 arm ### What issue are you seeing? On macOS Apple Silicon, long responses in the Codex/ChatGPT desktop app repeatedly jump/scroll upward while I am reading them. The bottom of the response becomes difficult or impossible to reach because the view moves back upward and leaves blank space below. The issue has existed since I installed the app. I have already submitted Feedback twice, and the problem remains after two app updates. The same conversations work normally in the browser/Safari. ### What steps can reproduce the bug? Feedback ID: no-active-thread-019fec9e-445a-7012-8d03-31fb1a31bd31 ### What is the expected behavior? when I write a question the text does not move up and up it just stays on the top level. ### Additional information _No response_", "url": "https://github.com/openai/codex/issues/37849", "createdAt": "2026-08-10T17:10:43Z", "updatedAt": "2026-08-12T15:56:43Z", "timestamp": "2026-08-12T15:56:43Z", "metrics": { "reactions": 0, "comments": 3 }, "labels": [ "bug", "app" ], "author": "rasettastone-art", "state": "open", "assignees": [], "change": "updated" }, { "id": "github:openai/codex:issue:37884", "source": "github", "group": "coding-agent-infrastructure", "project": "openai/codex", "kind": "issue", "title": "New ChatGPT App - Scrolling Issues", "text": "### What version of the Codex App are you using (From “About Codex” dialog)? 26.803.61601 ### What subscription do you have? ChatGPT Plus ### What platform is your computer? macOS 27.0 26A5406e (Darwin 27.0.0 arm64) ### What issue are you seeing? Scrolling behaves very weirdly in the new ChatGPT app vs ChatGPT Classic. I want to show a side by side comparison here (New ChatGPT on the left, ChatGPT Classic on the right). It's difficult to read along with the new ChatGPT app as it continues to scroll even when it doesn't need to, moving content up out of the view causing a huge gap of empty space at the bottom. This is only observable in regular chats, not in Work/Codex. https://github.com/user-attachments/assets/1c242bbe-d3dc-468b-b14e-1197eb989871 ### What steps can reproduce the bug? 1. Open both apps side by side. 2. Start a new regular chat in both and type \"type exactly 500 words\" then do it again to see how scrolling behaves in both. ### What is the expected behavior? It should behave how it did in the old ChatGPT Classic app. ### Additional information This is honestly the main reason keeping me from using the new app day to day, it's pretty much impossible to read along with what ChatGPT is doing, you have to constantly scroll up after every single message, it's very annoying.", "url": "https://github.com/openai/codex/issues/37884", "timestamp": "2026-08-12T13:09:03Z", "metrics": { "reactions": 0, "comments": 3 }, "labels": [ "bug", "app" ], "author": "falchion10", "assignees": [], "change": "new" }, { "id": "github:openai/codex:issue:37910", "source": "github", "group": "coding-agent-infrastructure", "project": "openai/codex", "kind": "issue", "title": "Unknown model gpt-5.6-luna", "text": "### What version of the IDE extension are you using? 26.803.61601 ### What subscription do you have? PRO 5X ### Which IDE are you using? VS CODE ### What platform is your computer? Windows ### What issue are you seeing? Unknown model gpt-5.6-luna when summoning it as a subagent. ### What steps can reproduce the bug? .codex adds luna, use sol to summon it. Using an old session started before the extension was updated. ### What is the expected behavior? Just summon luna as a subsagent ### Additional information _No response_", "url": "https://github.com/openai/codex/issues/37910", "createdAt": "2026-08-11T01:24:38Z", "updatedAt": "2026-08-13T05:17:52Z", "timestamp": "2026-08-13T05:17:52Z", "metrics": { "reactions": 1, "comments": 3 }, "labels": [ "bug", "windows-os", "extension", "subagent" ], "author": "Pawww28", "state": "open", "assignees": [] }, { "id": "github:openai/codex:issue:37913", "source": "github", "group": "coding-agent-infrastructure", "project": "openai/codex", "kind": "issue", "title": "Codex Remote on iOS displays raw Visualize content reference instead of rendering visualization", "text": "## Summary When a Codex task is viewed through ChatGPT Remote on iOS, a bundled Visualize result is displayed as the raw internal content-reference directive instead of rendering the visualization. The visualization itself is generated successfully on the Mac host and renders correctly at mobile width when opened locally. The failure is in the iOS Remote presentation layer: the client shows the internal `visualize` marker and an absolute host filesystem path as ordinary text. ## Environment - Host app: ChatGPT desktop `26.803.61601` (build `6396`) - Host OS: macOS `26.5.2` (`25F84`), arm64 - Bundled plugin: `visualize@openai-bundled` `1.0.20` - Client: ChatGPT app on iPhone, Codex Remote - iOS app version: not yet captured - Date reproduced: 2026-08-10 ## What the user sees Instead of an interactive visualization, the completed assistant message visibly contains a raw marker equivalent to: ```text [visualize content reference containing {\"path\":\"/Users//.codex/visualizations///.html\"}] ``` The real screenshot and path contain personal information, so they are intentionally not attached publicly. A sanitized screenshot can be supplied if maintainers need it. ## Steps to reproduce 1. Start or continue a local Codex task on a Mac host. 2. Connect to that host from ChatGPT on iPhone using Codex Remote. 3. Invoke the bundled Visualize plugin in the task. 4. Have Codex create a valid thread-scoped HTML fragment under the host visualization directory. 5. Return the documented visualization content reference in the final assistant response. 6. Open or complete the turn on iOS. 7. Observe that the iOS client displays the internal content-reference syntax and absolute local path as text instead of rendering the visualization. The behavior reproduced more than once in the same iOS Remote task. ## Control result The generated fragment was rendered locally with the bundled Visualize renderer and inspected at both 736 px and 360 px widths. It displayed correctly, including at the mobile viewport. This rules out malformed HTML or a mobile-layout failure in the fragment itself. ## Expected behavior On supported iOS clients and eligible accounts, the Codex task should render the inline visualization, consistent with the documented iOS support introduced in ChatGPT for iOS 1.2026.188. If the account, workspace, or app version is not eligible for the Visualizations preview, the client should show a graceful fallback or an actionable availability message. It should never expose the internal content-reference syntax or the host's absolute filesystem path. ## Actual behavior - No visualization is shown. - The internal Visualize directive appears literally in the completed assistant message. - The absolute Mac host path is exposed to the iOS user. - There is no fallback image, open action, relay-backed attachment, or availability error. ## Impact - Blocks review of visual work while away from the host. - Leaks implementation syntax that users should not need to understand. - Exposes a host-local absolute path, including information that may identify the local account. - Makes a successful generation look like an agent failure even though the artifact exists and renders correctly on the host. ## Related reports - #25202 — Remote mobile Codex does not render local media artifacts linked from assistant messages - #35371 — Codex Remote on iOS shows tool images during execution but drops them from the completed turn Those reports cover adjacent Remote media/replay failures. A repository search did not find an existing issue specifically for raw Visualize content-reference syntax appearing on iOS. ## Documentation - https://learn.chatgpt.com/docs/visualizations#check-availability - https://learn.chatgpt.com/docs/whats-new#inspect-codex-task-visualizations-on-ios ## Suggested fix area The iOS completed-turn renderer should recognize and resolve Visualize content references through the supported relay/preview mechanism. Unsupported clients should receive a sanitized fallback. Raw directives and absolute host paths should never be rendered directly to the user.", "url": "https://github.com/openai/codex/issues/37913", "createdAt": "2026-08-11T01:44:23Z", "updatedAt": "2026-08-13T14:08:07Z", "timestamp": "2026-08-13T14:08:07Z", "metrics": { "reactions": 0, "comments": 1 }, "labels": [ "bug", "iOS", "remote" ], "author": "johnsilvavlogs", "state": "open", "assignees": [] }, { "id": "github:openai/codex:issue:37916", "source": "github", "group": "coding-agent-infrastructure", "project": "openai/codex", "kind": "issue", "title": "[App Server] stale watched_status overrides completed subagent state during thread enrichment", "text": "### What version of the Codex App are you using (From “About Codex” dialog)? Originally reproduced on `26.803.41515` (build `6321`) with bundled `codex-cli 0.147.0-alpha.6.5`. The current installation is `26.803.61601` (build `6396`) with the same bundled CLI version. The relevant reconciliation code is also unchanged on current `main` at `070a26a1f00817931a17e2cdf8fbe03a2a0ed128` (2026-08-11). ### What subscription do you have? ChatGPT subscription. The exact tier is not exposed by the local diagnostics used for this report. ### What platform is your computer? `Darwin 25.2.0 arm64 arm` ### What issue are you seeing? Codex Desktop can keep a completed subagent under **Active / Working**, even after the child emitted a final answer and `task_complete` and the parent received the result. The source contains a deterministic status-precedence problem in [`enrich_loaded_threads`](https://github.com/openai/codex/blob/070a26a1f00817931a17e2cdf8fbe03a2a0ed128/codex-rs/app-server/src/request_processors/thread_enrichment.rs#L13-L73): 1. A cached `watched_status` is copied into `thread.status` first. 2. The loaded child then reports `AgentStatus::Completed(_)` or `Interrupted`. 3. That authoritative status changes the thread to `Idle` only when `watched_status.is_none()`. Therefore this input remains incorrectly active: ```text watched_status = Active loaded agent_status = Completed(...) enriched thread.status = Active # current result ``` This matches the observed Desktop behavior: opening a completed child can refresh it into Done, while an unopened child remains Working indefinitely. This report is intentionally narrower than the existing UI reports: it identifies one concrete reconciliation branch that lets a stale watch-cache value override the loaded agent's terminal state. ### What steps can reproduce the bug? UI reproduction: 1. Start a parent task that spawns one or more subagents. 2. Let a child return its final answer and emit `task_complete`. 3. Do not open the child's detail view. 4. Open the parent task's Subagents panel. 5. Observe that the terminal child can remain under Active / Working. 6. Open that child and navigate back. Its card may then move to Done, indicating that navigation forced a refresh that normal enrichment missed. Deterministic regression-test shape: 1. Provide `enrich_loaded_threads` a spawned-child thread whose watch manager returns `ThreadStatus::Active`. 2. Make `thread_manager.get_thread(...).agent_status()` return `AgentStatus::Completed(...)`. 3. Assert that the enriched status is not Active / Working. The current implementation leaves it Active because the terminal branch is guarded by `watched_status.is_none()`. ### What is the expected behavior? - A loaded child whose authoritative agent status is terminal must not be presented as actively Working merely because the watch cache still contains Active. - The enrichment path should reconcile freshness or let a terminal loaded status override stale Active state. - Add a regression test for `watched Active + loaded Completed` and the equivalent interrupted/error paths. - Opening the child detail view should not be required to move it out of Active. An `open` spawn edge may intentionally mean that a completed child is resumable. This report is **not** requesting that every `task_complete` automatically close or archive the edge. It is requesting that resumable/idle history not be classified as actively executing. ### Additional information Related symptom reports: - #35209 — completed subagents remain Active after `task_complete` - #37563 — terminal/closed children rehydrate as Working after restart - #37729 — completed children move only after their results are opened - #23930 — closed/readback-missing agents remain visible Current Multi-Agent V2 does not expose the V1 `close_agent` lifecycle tool, so users cannot reliably repair this state from the parent task. A local diagnostic forced the same model through V1 and verified that explicit close transitions the persisted child edge to `closed`; that avoids accumulation but is a compatibility workaround, not a product fix. No database was modified. State inspection was read-only. No thread IDs, prompts, project names, repository paths, screenshots, credentials, or private task content are included.", "url": "https://github.com/openai/codex/issues/37916", "createdAt": "2026-08-11T02:40:20Z", "updatedAt": "2026-08-13T16:36:36Z", "timestamp": "2026-08-13T16:36:36Z", "metrics": { "reactions": 0, "comments": 3 }, "labels": [ "bug", "app", "subagent", "app-server" ], "author": "Yida147", "state": "open", "assignees": [] }, { "id": "github:openai/codex:issue:37932", "source": "github", "group": "coding-agent-infrastructure", "project": "openai/codex", "kind": "issue", "title": "[Windows] Computer Use cannot enumerate or launch desktop apps on one machine", "text": "## Environment - Codex App: 26.803.10989.0 (Windows AppX package version) - Computer Use plugin: 26.803.81509 - Platform: Microsoft Windows NT 10.0.26200.0 x64 - Subscription: ChatGPT subscription; exact tier unknown ## Issue Computer Use in the Codex desktop app cannot see or control any desktop apps on this Windows PC. The same account and workflow work normally on other computers. Observed errors/states: - Importing `@oai/sky` can fail with: `EPERM: operation not permitted, lstat 'C:\\Users\\\\AppData\\Local\\OpenAI\\Codex'`. - On retries where the module loads, `list_apps()` and `list_windows()` both return zero items even while WeChat is open. - Launching `C:\\Program Files\\Tencent\\Weixin\\Weixin.exe` or `Weixin.exe` may fail with: `failed to fetch shell:AppsFolder item: 找不到元素。 (0x80070490)`. Result: Codex cannot open/control WeChat and cannot send a test message to File Transfer Assistant. ## Reproduction 1. Open the Codex desktop app on the affected Windows PC. 2. Enable the Computer Use plugin/server and “Any App”, grant permissions, and unlock the session. 3. Open WeChat manually. 4. Ask Codex to use Computer Use to send a message to File Transfer Assistant. 5. Computer Use either fails while loading `@oai/sky`, returns zero apps/windows, or fails to launch WeChat with error `0x80070490`. The same account and task work normally on other computers. ## Expected behavior Computer Use should enumerate the open desktop windows and interact with WeChat, as it does on the user's other computers. ## Troubleshooting already attempted - Unlocked the session and granted all requested permissions. - Enabled “Any App”. - Restarted and retried the Computer Use plugin. - Reinstalled/retried the plugin. - Fully uninstalled and reinstalled the official Codex Windows app; the problem persists. No raw logs, session ID, or other PII are attached.", "url": "https://github.com/openai/codex/issues/37932", "createdAt": "2026-08-11T03:55:33Z", "updatedAt": "2026-08-13T12:04:01Z", "timestamp": "2026-08-13T12:04:01Z", "metrics": { "reactions": 0, "comments": 4 }, "labels": [ "bug", "windows-os", "app", "computer-use" ], "author": "277644921-star", "state": "open", "assignees": [] }, { "id": "github:openai/codex:issue:37968", "source": "github", "group": "coding-agent-infrastructure", "project": "openai/codex", "kind": "issue", "title": "Codex App window repeatedly turns completely blank after renderer crashes", "text": "### What version of the Codex App are you using (From “About Codex” dialog)? 26.803.61601 (build 6396); bundled codex-cli 0.147.0-alpha.6.5 ### What subscription do you have? ChatGPT subscription (exact tier is not displayed in the Codex App) ### What platform is your computer? macOS 26.5.1 (Build 25F80), Apple Silicon arm64; Darwin 25.5.0 ### What issue are you seeing? The Codex App window intermittently becomes completely blank while multiple important tasks are running. Restarting the app restores the UI, but the interruption has caused important tasks to be left unfinished or difficult to recover. Local Crashpad records show repeated renderer crashes. On 2026-08-11 (Asia/Shanghai), renderer crash records were created at 16:09:11, 16:12:59, and 16:17:31. The same machine also has renderer crash records from 2026-08-10 at 10:42:54 and 20:24:25. This appears to be a UI renderer failure rather than a project/workspace error. No project names, task content, account identifiers, or raw logs are included here. ### What steps can reproduce the bug? The issue is intermittent, but the most consistent sequence observed in the local app logs is: 1. Run multiple Codex tasks concurrently. 2. At least one task starts or uses the Codex in-app Browser. 3. Within several seconds, a renderer crash is recorded. 4. The app UI may become entirely blank. 5. Quit and restart the Codex App; the UI returns. Examples on 2026-08-11 (Asia/Shanghai): - 16:09:04 in-app Browser session startup → 16:09:11 renderer crash. - 16:12:44 in-app Browser session startup → 16:12:59 renderer crash. - 16:17:28 in-app Browser session startup → 16:17:31 renderer crash. After these events, app logs report messages such as: - `route window is not live` - `No ChatGPT browser route is available` - `host did not respond to sync request` No system memory-pressure or jetsam event was recorded at the incident time. Restarting the app is the only reliable recovery I have found. ### What is the expected behavior? A renderer or in-app Browser failure should not blank the entire Codex App. If a child renderer crashes, the app should automatically recover the affected view while keeping task state and active runs accessible. ### Additional information Impact: High. This has happened repeatedly and has interrupted important long-running work, leaving some tasks unfinished. The app updated/relaunched around 16:11 on 2026-08-11, but renderer crashes occurred both before and after that update, so the update alone does not explain the issue. The app was using substantial memory at the time, but the macOS system had no recorded memory-pressure event and still had ample available memory. The strongest correlation is with in-app Browser session startup. I can provide the relevant redacted app-log excerpts privately if maintainers need them.", "url": "https://github.com/openai/codex/issues/37968", "createdAt": "2026-08-11T09:07:28Z", "updatedAt": "2026-08-13T14:55:49Z", "timestamp": "2026-08-13T14:55:49Z", "metrics": { "reactions": 1, "comments": 2 }, "labels": [ "bug", "app", "browser" ], "author": "JJGGu", "state": "open", "assignees": [] }, { "id": "github:openai/codex:issue:37974", "source": "github", "group": "coding-agent-infrastructure", "project": "openai/codex", "kind": "issue", "title": "TUI: queued follow-up inputs are permanently stranded after a failed prompt-edit branch", "text": "### What version of Codex CLI is running? codex-cli 0.147.0 ### What platform is your computer? Linux 5.15.120 x86_64 (also reproducible on other platforms — the bug is in the TUI prompt-edit/backtrack logic, not platform-specific) ### What issue are you seeing? When editing an earlier prompt (Esc-Esc backtrack → select a prompt → Enter), the TUI forks the thread *before* the selected turn. If that fork fails — e.g. the composer shows: ``` ■ Failed to branch before the selected prompt: the selected prompt was not found in the persisted thread ``` — then **any user inputs that were queued while the fork was in flight get permanently stranded**. They stay in \"Queued follow-up inputs\" forever and are never submitted, even after the composer returns to the `Ready` state. The queue just keeps growing with every new message and nothing is ever sent to the model. Note: the \"not found in the persisted thread\" guard itself is legitimate defensive behavior (the visible transcript projection can't always be matched back to a persisted turn — e.g. after history pagination, or when large context blocks are injected as user messages by a wrapper). The bug is purely in the **failure-handling path**, which forgets to re-drive the input queue. ### Root cause Every *successful* fork path re-drives the follow-up input queue via `maybe_send_next_queued_input()`: - the sibling `AppEvent::ForkSession` handler (`codex-rs/tui/src/app/event_dispatch.rs`), - the startup path (`handle_startup_thread_started`), - the thread-start path. But the branch-**failure** path does not. In `codex-rs/tui/src/app_backtrack.rs`: ```rust pub(crate) fn restore_backtrack_prompt_after_branch_error( &mut self, prompt: UserMessage, err: impl std::fmt::Display, ) { self.chat_widget.restore_user_message_to_composer(prompt); self.chat_widget.add_error_message(format!( \"Failed to branch before the selected prompt: {err}\" )); // <-- missing: maybe_send_next_queued_input(); the current thread is still live, // but queued follow-ups are never re-driven, so they stay stuck forever. } ``` Since the fork failed, the original thread stays live, but the queue is never flushed, so queued inputs are stranded. ### What steps can reproduce the bug? 1. In a live thread, enqueue one or more follow-up inputs (e.g. queue messages while a turn is running, or via a wrapper that injects inputs). 2. Trigger prompt editing (Esc-Esc backtrack) and select a prompt whose fork will fail — the reliable way to force the failure is any state where the selected transcript prompt can't be resolved back to a persisted turn (`the selected prompt was not found in the persisted thread`). 3. Observe that after the error, the composer returns to `Ready`, but the queued follow-up inputs remain in \"Queued follow-up inputs\" and are never submitted. ### What is the expected behavior? After a failed prompt-edit branch, since the current thread is still live, queued follow-up inputs should be submitted once the composer is idle — exactly like every successful fork path already does. ### Additional information I have a minimal fix and regression test ready (one-line fix + a test asserting the queued input is submitted after a failed prompt-edit branch, verified to fail without the fix and pass with it). openai/codex does not appear to accept PRs from external forks, so I'm filing this issue instead. Happy to share the patch/branch if useful: ```rust pub(crate) fn restore_backtrack_prompt_after_branch_error( &mut self, prompt: UserMessage, err: impl std::fmt::Display, ) { self.chat_widget.restore_user_message_to_composer(prompt); self.chat_widget.add_error_message(format!( \"Failed to branch before the selected prompt: {err}\" )); // The prompt edit never took effect, so the current thread stays live. Follow-up inputs // queued while the fork was in flight would otherwise remain stuck, because unlike the // successful fork paths this branch never re-drives the queue. Flush it here so queued // messages are submitted once the composer is idle again. self.chat_widget.maybe_send_next_queued_input(); } ```", "url": "https://github.com/openai/codex/issues/37974", "createdAt": "2026-08-11T09:42:39Z", "updatedAt": "2026-08-13T17:59:47Z", "timestamp": "2026-08-13T17:59:47Z", "metrics": { "reactions": 8, "comments": 1 }, "labels": [ "bug", "TUI", "CLI", "session" ], "author": "nil-err", "state": "open", "assignees": [], "change": "new" }, { "id": "github:openai/codex:issue:38003", "source": "github", "group": "coding-agent-infrastructure", "project": "openai/codex", "kind": "issue", "title": "Intel macOS: Computer Use startup fails after 26.803.61601 (250 ms native-pipe timeout; managed helper absent)", "text": "### OpenAI feedback thread `019ff0ed-18c7-7983-a939-09d9e861e0ec` (submitted with no diagnostic-log upload) ### What version of the Codex App are you using? ChatGPT/Codex desktop `26.803.61601` (build `6396`), with a valid OpenAI Developer ID signature. Bundled runtime: - `@oai/sky 0.6.6` - `cua_node` Node `24.14.0` - target `darwin-x64` ### What subscription do you have? Not included in this public report. ### What platform is your computer? macOS 14.8.8 (23J620), Intel x86_64. ### What issue are you seeing? Computer Use could not initialize after the desktop update. The app log reported: ```text Failed to reconcile managed Computer Use service Failed to spawn managed Computer Use service ``` Two direct calls through the currently bundled package: ```js await (await import(\"@oai/sky\")).sky.list_apps() ``` both failed with: ```text Sky Computer Use service startup request failed ``` Screen Recording, Accessibility, event-post, and event-listen permissions were granted, and the console session was unlocked. The signed x86_64 app bundle contains `@oai/sky`, but it does not contain: - `Codex Computer Use.app` - a bundled `computer-use` plugin - the older `@oai/cua` package This leaves the managed-service fallback with no helper payload to spawn. ### Steps to reproduce 1. Install/update the Intel macOS desktop app to `26.803.61601`. 2. Enable Computer Use and grant Screen Recording and Accessibility. 3. Fully relaunch the desktop app. 4. Invoke Computer Use or call `sky.list_apps()`. 5. Observe `Sky Computer Use service startup request failed`. 6. Inspect the signed x86_64 app resources and observe that the managed helper/plugin payload is absent. ### Expected behavior Computer Use should initialize and list/capture approved apps on a supported Intel Mac after permissions are granted. If Intel is no longer supported, the app should report that explicitly instead of installing a `darwin-x64` runtime that falls through to a missing managed service. ### Root cause found locally The `@oai/sky 0.6.6` native-pipe path gives the first connect-and-ping attempt a 250 ms budget. A local Intel compatibility service performs Security.framework peer validation before handling requests: - same UID - peer PID - OpenAI Team ID `2DC432GLL2` - expected signed Codex/Node identity and trusted ancestor A real ping took 287 ms. The client therefore timed out, invoked the host's managed-service path, and then failed because this x86_64 build has no managed helper to spawn. ### Local compatibility repair The repair preserved authorization for every operation and changed only the harmless handshake path: 1. Parse only the first framed JSON-RPC message. 2. If it is a valid `CodexComputerUseIPC-2` `ping`, immediately return `serverApiVersion`. This response exposes no app data and performs no action. 3. Pause and buffer all remaining frames. 4. Run the unchanged Security.framework fd-peer authorization. 5. Process list/state/action requests only after authorization succeeds. 6. If the first message is not a ping, keep it buffered and authorization-gated for backward compatibility. 7. Update the compatibility skill bootstrap from the removed `@oai/cua` plus `initialize()` path to: ```js globalThis.sky ??= (await import(\"@oai/sky\")).sky; ``` No authentication, app-policy, screenshot, or input-event check was bypassed. ### Validation after the repair - A deterministic regression delays peer authorization by 600 ms while requiring the ping response within 250 ms. - Source and installed plugin-cache suites: 16/16 tests passed. - Real ping latency: 287 ms before, 25 ms after. - The official bundled `@oai/sky` client returned six valid app IDs from `list_apps()`. - A read-only Finder `get_app_state` returned a file screenshot and 12,351 characters of accessibility text. - No click or keyboard input was used, and the temporary screenshot was removed. ### Suggested product fixes - Bundle and sign an x86_64 or universal `Codex Computer Use.app` plus the `computer-use` plugin in the Intel desktop build, or make the managed-service path discover an already-running compatible service. - Increase the initial direct-connect/ping budget above realistic code-signing verification latency, or explicitly support a data-free unauthenticated ping followed by authenticated request processing. - Keep the helper payload, plugin catalog, runtime package, and bundled skill/docs consistent when moving from `@oai/cua` to `@oai/sky`. - Preserve the nested startup cause in the user-visible error.", "url": "https://github.com/openai/codex/issues/38003", "createdAt": "2026-08-11T13:08:26Z", "updatedAt": "2026-08-12T21:37:48Z", "timestamp": "2026-08-12T21:37:48Z", "metrics": { "reactions": 1, "comments": 1 }, "labels": [ "bug", "app", "computer-use" ], "author": "gpxsrz", "state": "open", "assignees": [] }, { "id": "github:openai/codex:issue:38005", "source": "github", "group": "coding-agent-infrastructure", "project": "openai/codex", "kind": "issue", "title": "Allow cross-thread communication between agents", "text": "### What variant of Codex are you using? IDE Extension and CLI ### What feature would you like to see? Allow agents running in different threads to communicate with each other. This would enable an agent in one thread to send messages, requests, or relevant context to an agent in another thread, making it possible to coordinate work across independent conversations or tasks. Ideally, agents should be able to: * Identify or address another active agent/thread. * Send messages or structured data across threads. * Receive responses without merging the threads or their full contexts. * Maintain clear attribution of which agent/thread sent each message. This would be useful for multi-agent workflows where separate agents handle different parts of a task but still need to coordinate. ### Additional information _No response_", "url": "https://github.com/openai/codex/issues/38005", "createdAt": "2026-08-11T13:15:41Z", "updatedAt": "2026-08-13T14:45:15Z", "timestamp": "2026-08-13T14:45:15Z", "metrics": { "reactions": 0, "comments": 2 }, "labels": [ "enhancement", "extension", "CLI", "subagent" ], "author": "rafaself", "state": "closed", "assignees": [] }, { "id": "github:openai/codex:issue:38029", "source": "github", "group": "coding-agent-infrastructure", "project": "openai/codex", "kind": "issue", "title": "[Windows app regression] Subagent threads lose direct visibility/control and Spark is missing from spawn overrides", "text": "# [Windows app regression] Subagent threads lose direct visibility/control and Spark is missing from spawn overrides ### What version of the Codex App are you using (From “About Codex” dialog)? MSIX package version `26.803.10989.0` (Microsoft Store package, status OK). ### What subscription do you have? Not collected. The report is about the locally advertised Desktop/tool capabilities rather than an inferred subscription entitlement. ### What platform is your computer? Microsoft Windows NT `10.0.26200.8875`, x64 (Windows 11 25H2). ### What issue are you seeing? Codex Desktop has regressed in two closely related subagent areas: 1. **Subagent visibility and user control.** Previously, spawned subagents appeared as independently visible tasks/chats. A user could open a child thread, see its selected model and reasoning effort, send a follow-up or correction directly, and change the child model/settings. In the current app, child activity is exposed only through a restricted parent-owned Subagents surface. The user cannot manage a child as a normal task, and the effective model/reasoning effort is not shown. 2. **Spark routing inconsistency.** `gpt-5.3-codex-spark` is currently advertised for normal Codex task creation and continuation, but the live `spawn_agent` contract exposes explicit model overrides only for `gpt-5.6-sol` and `gpt-5.6-terra`. Spark was previously used successfully for real subagent sessions on this same installation/account. This is inconsistent with the current official subagent documentation, which says that the app surfaces each subagent thread for inspection, documents per-agent model/reasoning configuration, and includes current custom-agent examples that explicitly use `gpt-5.3-codex-spark` with `model_reasoning_effort = \"medium\"`: https://learn.chatgpt.com/docs/agent-configuration/subagents ### What steps can reproduce the bug? 1. Open Codex Desktop and start a normal Codex task. 2. Inspect the normal task-creation model capability. `gpt-5.3-codex-spark` is offered, with `low`, `medium`, `high`, and `xhigh` reasoning efforts. 3. Ask the parent agent to spawn a child using `gpt-5.3-codex-spark` and a fresh/no-history fork. 4. Inspect the live `spawn_agent` schema. Its explicit `model` override is limited to `gpt-5.6-sol` and `gpt-5.6-terra`; Spark cannot be requested through that interface. 5. Spawn a child using any currently accepted route. 6. Open the Desktop Subagents activity surface. 7. Observe that the child is not presented with the same independent task/chat controls as before. The UI does not show the child’s effective model and reasoning effort, and the user cannot directly send a correction/follow-up or change model/settings on the child thread. Steering is available only indirectly through parent-agent control tools. ### What is the expected behavior? - Every spawned child should be surfaced as an openable, independently inspectable child task/thread. - The child UI should show the effective resolved model and reasoning effort, not merely parent metadata or no metadata. - After explicitly opening/selecting a child, the user should be able to send a correction, steer an active turn, continue an idle/completed child, and change supported model/reasoning settings. - Normal-task and subagent model routing should be consistent. If Spark is available for normal Codex tasks and documented for custom subagents, it should either be an accepted `spawn_agent` override or the product should clearly document and surface why it is unavailable for subagents. - If direct child input is intentionally restricted, that restriction should be explicit in the UI and documentation, with a visible effective model/effort and a first-class user control path rather than an opaque parent-only relay. ### Actual behavior - The current Desktop UI exposes a restricted parent-owned Active/Done subagent surface rather than the earlier independently controllable task/chat experience. - Effective child model and reasoning effort are not visible. - Direct user follow-up/steering/settings changes on child threads are unavailable; only parent-agent relay/control tools are exposed. - Normal task creation and continuation advertise Spark, but the current `spawn_agent` override enum omits it. ### Privacy-safe diagnostics - Current normal task-creation/continuation contract advertises: - `gpt-5.6-sol` - `gpt-5.6-terra` - `gpt-5.6-luna` - `gpt-5.5` - `gpt-5.4` - `gpt-5.4-mini` - `gpt-5.3-codex-spark` (`low`, `medium`, `high`, `xhigh`) - Current `spawn_agent` contract advertises explicit model overrides only for: - `gpt-5.6-sol` - `gpt-5.6-terra` - Current parent-side subagent controls include follow-up/message delivery, interrupt, list, and wait operations. They do not restore the earlier direct user task/thread interaction surface. - Privacy-safe local rollout metadata shows: - August 1–7: 26 actual subagent sessions used `gpt-5.3-codex-spark` with effort `medium`. - Latest observed Spark subagent rollout: August 7, 2026. - August 10–11: 157 readable actual subagent sessions used Terra, Luna, Sol, or automatic review adapters; zero used Spark. - No task content, project identifiers, paths, source code, or business data was inspected or included in these counts. - Local package deployment history shows several rapid updates between July 30 and August 11. The current `26.803.10989.0` build was installed on August 11. The exact first bad build is not proven, but the observed routing cutover is between August 7 and August 10. ### Custom-agent routing check A project-scoped, read-only custom agent was defined in an isolated scratch task using the documented settings: ```toml model = \"gpt-5.3-codex-spark\" model_reasoning_effort = \"medium\" sandbox_mode = \"read-only\" ``` The current live session rejected the custom role as `unknown agent_type` before creating a child. This proves only that the current session’s adapter/role registry did not discover the newly added custom role. It does **not** prove that the backend rejected Spark model authorization, because no model-routed spawn request reached the backend. A fresh-session custom-role test would be needed to separate successful adapter discovery from backend model authorization. No global Codex configuration was changed. ### Regression timeframe - Last known successful Spark subagent metadata: August 7, 2026. - First observed two-day period with 157 non-Spark subagent sessions and zero Spark sessions: August 10–11, 2026. - Current app build: `26.803.10989.0`, installed August 11, 2026. - Therefore the evidence narrows the routing regression to August 7–10, but does not identify the exact responsible app/runtime build. ### Related upstream reports - #32488 — subagent panel omissions in the Desktop app - #33885 — MultiAgentV2 child threads reject direct corrections/steering - #32031 — MultiAgentV2 spawn schema hides model overrides - #31893 — documented custom agents can become unusable through the restricted schema - #27624 — Desktop reasoning-effort handling/display regression (closed) This report adds a current Windows build, an observed regression window, direct schema parity evidence, and a statistically bounded Spark-before/after metadata sample without exposing any private task or workspace information.", "url": "https://github.com/openai/codex/issues/38029", "createdAt": "2026-08-11T16:02:58Z", "updatedAt": "2026-08-12T15:14:07Z", "timestamp": "2026-08-12T15:14:07Z", "metrics": { "reactions": 0, "comments": 2 }, "labels": [ "bug", "windows-os", "app", "subagent" ], "author": "gNikro", "state": "open", "assignees": [], "change": "updated" }, { "id": "github:openai/codex:issue:38039", "source": "github", "group": "coding-agent-infrastructure", "project": "openai/codex", "kind": "issue", "title": "Windows standalone auto-upgrade installs a broken AppData CLI launcher without sandbox resources", "text": "### What version of Codex CLI is running? `codex-cli 0.147.0` ### What platform is your computer? Microsoft Windows NT 10.0.26200.0 ARM64 ### What issue are you seeing? After the Windows standalone auto-upgrade from 0.146.0 to 0.147.0, `codex` resolved first to: ```text %LOCALAPPDATA%\\Programs\\OpenAI\\Codex\\bin\\codex.exe ``` The updater copied the new `codex.exe` and `codex-code-mode-host.exe` there, but did not install the required `codex-resources` directory beside that executable. As a result, every sandboxed command failed before PowerShell launched: ```text windows sandbox: orchestrator_helper_launch_failed: setup refresh failed to launch helper: helper=codex-windows-sandbox-setup.exe error=program not found ``` The complete versioned release was present under: ```text %USERPROFILE%\\.codex\\packages\\standalone\\releases\\0.147.0-aarch64-pc-windows-msvc ``` and contained: ```text codex-resources\\codex-windows-sandbox-setup.exe codex-resources\\codex-command-runner.exe ``` The `codex.exe` in the AppData launcher directory and the versioned release had identical SHA-256 hashes. The difference was solely their resource-relative installation layout. This leaves a launcher that passes `codex --version` but cannot execute any sandboxed tool, making the upgrade appear successful while the CLI is functionally broken. ### What steps can reproduce the bug? 1. Install the standalone Codex CLI on Windows ARM64. 2. Allow it to auto-upgrade from 0.146.0 to 0.147.0. 3. Confirm both paths exist: - `%LOCALAPPDATA%\\Programs\\OpenAI\\Codex\\bin\\codex.exe` - `%USERPROFILE%\\.codex\\packages\\standalone\\releases\\0.147.0-aarch64-pc-windows-msvc\\bin\\codex.exe` 4. Put the AppData `bin` directory first on PATH, or invoke that executable directly. 5. Start Codex with the native Windows sandbox. 6. Ask it to run a trivial shell command such as `Get-Location`. ### What is the expected behavior? The auto-upgrade should leave the public `codex` entrypoint able to locate the matching version's sandbox setup and command-runner helpers. The updater could achieve this by installing a resource-aware launcher/shim, preserving the versioned executable location, or installing the matching `codex-resources` beside the AppData executable. It should also validate a sandboxed command after upgrade, not only `codex --version`. ### Workaround verified A small `%USERPROFILE%\\.local\\bin\\codex.cmd` launcher that selects the newest versioned release and executes its `bin\\codex.exe` fixes the problem. After restoring that wrapper and restarting Codex: - sandbox setup launched from the versioned `codex-resources` directory; - writes inside the workspace succeeded; - writes outside the workspace were denied; - package formatting, lint, typecheck, and 198 tests passed. ### Additional information The sandbox log clearly distinguishes the broken and working launch paths. Broken AppData launcher: ```text setup refresh: spawning codex-windows-sandbox-setup.exe setup refresh failed to launch helper: ... error=program not found ``` Working versioned launcher: ```text setup refresh: spawning %USERPROFILE%\\.codex\\packages\\standalone\\releases\\0.147.0-aarch64-pc-windows-msvc\\codex-resources\\codex-windows-sandbox-setup.exe setup refresh: processed 2 write roots (read roots delegated); errors=[] setup binary completed ``` Related: #37049, #32655, #37575. This report focuses specifically on the auto-upgrade completing while leaving the public AppData launcher structurally incomplete.", "url": "https://github.com/openai/codex/issues/38039", "createdAt": "2026-08-11T17:22:39Z", "updatedAt": "2026-08-13T07:21:52Z", "timestamp": "2026-08-13T07:21:52Z", "metrics": { "reactions": 0, "comments": 2 }, "labels": [ "bug", "windows-os", "sandbox", "CLI" ], "author": "Luligu", "state": "open", "assignees": [] }, { "id": "github:openai/codex:issue:38055", "source": "github", "group": "coding-agent-infrastructure", "project": "openai/codex", "kind": "issue", "title": "[Windows][26.803.10989.0][SSH Remote] Send stalls with a 5–6 GB memory spike and delayed queued/Steer delivery; ~100 KB attachments can crash", "text": "### What version of the Codex App are you using (From “About Codex” dialog)? 26.803.10989.0 ### What subscription do you have? ChatGPT Pro ### What platform is your computer? Microsoft Windows NT 10.0.26200.0 x64 ### What issue are you seeing? ## Summary Codex Desktop `26.803.10989.0` on Windows becomes unreliable when sending messages to an SSH remote. There are two related failure modes: 1. A plain-text message enters an ambiguous delayed-delivery state. Memory rises to approximately 5–6 GB and later falls to approximately 4 GB. The Send button becomes available again, and a subsequent Send interaction displays the message as queued with a `Steer` action. The message is temporarily absent from the same conversation on Android, but after restarting the Windows app it is eventually delivered and begins processing. 2. Sending two small local text attachments, approximately 100 KB combined, can make memory reach approximately 10 GB and cause the entire application to exit silently. Both behaviors reproduce after a complete reset of the local Windows Codex profile and Microsoft Store/MSIX application data. ## Environment - Codex Desktop / Microsoft Store package: `OpenAI.Codex 26.803.10989.0` - Architecture: x64 - Platform: `Microsoft Windows NT 10.0.26200.0 x64` - Subscription: ChatGPT Pro - Target environment: SSH remote - The same SSH remote and conversations are accessible and usable through ChatGPT on Android ## Failure mode 1: plain-text message, memory spike, and delayed queued delivery I opened a conversation associated with an SSH remote and sent a simple plain-text message with no attachments. Observed sequence: 1. I clicked Send. 2. The Send button became disabled. 3. The turn did not visibly enter Thinking or Reasoning. 4. The ChatGPT/Codex process group increased to approximately 5–6 GB of memory. 5. Memory later fell to approximately 4 GB. 6. At approximately the same time, the Send button became available again. 7. I clicked Send again. 8. The message then appeared in Windows Desktop with a `Steer` action, as if it had been queued behind an active turn rather than submitted normally. 9. I opened the exact same conversation through ChatGPT on Android. 10. At that moment, the message displayed by Windows was absent from the Android conversation. 11. I later closed and reopened ChatGPT/Codex on Windows. 12. After reopening the app, the previously queued message appeared in the conversation and began processing. 13. I clicked Stop, and the Stop action was accepted. The message was therefore not permanently lost. Instead, the Windows client temporarily provided no reliable indication of whether the message had been: - accepted by the remote; - locally queued; - committed to the shared conversation; - waiting to steer an existing turn; - or still pending submission. The plain-text case does **not** produce continuously unbounded memory growth. Memory rises to approximately 5–6 GB and then decreases to approximately 4 GB. However, the submission, queue, and active-turn state remain ambiguous until the application is restarted. This behavior creates a duplicate-execution risk. While Windows makes the original message look unsent or merely queued, the user may resend the same instruction from Windows or Android. The original message may then be delivered later. ## Failure mode 2: small text attachments cause high memory use and silent exit I also reproduced a more severe failure with two small local text files, approximately 100 KB combined. ### Reproduction where both attachments completed uploading 1. I opened a conversation on the same SSH remote. 2. I attached the two text files. 3. Both files appeared to complete uploading. 4. I clicked Send. 5. The turn did not visibly enter Thinking or Reasoning. 6. Application memory increased to approximately 10 GB. 7. The entire Windows application then exited silently. ### Reproduction with Troubleshooting performance recording enabled After a full Windows restart: 1. I enabled the built-in Troubleshooting performance recording. 2. I attempted to attach the same files. 3. The first attachment completed. 4. The second attachment remained stuck during attachment/upload processing. 5. Application memory reached approximately 5–6 GB. 6. I stopped the performance recording before allowing the application to reach another 10 GB failure. 7. I attempted to submit or preserve the trace, but I could not confirm whether it was successfully uploaded because the application exits before displaying a reliable confirmation. No feedback/session ID was displayed, so the trace submission status is unknown. ## Clean-profile isolation Before the final reproduction, I performed a complete local Windows profile reset: 1. Backed up and disabled the previous Windows `%USERPROFILE%\\.codex` directory. 2. Backed up the Microsoft Store application profile. 3. Reset the `OpenAI.Codex` MSIX application data. 4. Restarted Windows. 5. Signed into the application again. 6. Did not restore the old `config.toml`. 7. Did not restore the previous plugins, MCP configuration, or cached local state. 8. Added the SSH connection again. 9. Added the remote projects again. 10. Reproduced the attachment failure in the previous conversation. 11. Reproduced the plain-text submission problem in another conversation. The issue therefore does not appear to be caused by: - the previous local `.codex` profile; - the old `config.toml`; - old plugin or MCP settings; - cached MSIX application data; - one specific conversation; - or the attachment files alone. The same SSH remote continues to work through ChatGPT on Android, which suggests that the remote host and remote project are functional and that the failure is specific to the Windows Desktop client or its SSH remote message/turn synchronization path. ## Diagnostics - Troubleshooting performance recording was enabled during one attachment reproduction. - The recording was stopped before another high-memory crash. - Trace submission status is unknown. - No feedback/session ID was shown before the application exited. - No relevant Codex Windows Error Reporting event was found for the latest silent exits on `26.803.10989.0`. - A `RADAR_PRE_LEAK_64` event found for `firefox.exe` was unrelated and is not part of this report. A performance trace may exist in the backed-up local application data. I can provide it through a secure/private channel if requested by a maintainer and if it can be located and reviewed for private content. ## Possibly related issues These appear related but are not exact duplicates: - #37829 — Windows renderer memory growth and hang on package `26.803.5235.0` - #24287 — Desktop accepts a prompt but loses reliable turn/stream state; resent prompts may later appear as steered continuations - #35207 — cross-device queue and active-turn state desynchronization ### What steps can reproduce the bug? ### Plain-text delayed-delivery reproduction 1. Install or update Codex Desktop for Windows to `26.803.10989.0`. 2. Add a working SSH remote. 3. Open a conversation associated with a project on that SSH remote. 4. Enter a simple plain-text message with no attachments. 5. Click Send. 6. Observe that: - Send becomes disabled; - the turn does not visibly enter Thinking or Reasoning; - application memory rises to approximately 5–6 GB. 7. Wait until memory falls to approximately 4 GB and Send becomes available again. 8. Click Send again. 9. Observe that the message appears with a `Steer` action, as if queued behind an active turn. 10. Open the exact same conversation through ChatGPT on Android. 11. Observe that the message is not yet visible there. 12. Close and reopen ChatGPT/Codex on Windows. 13. Observe that the previously queued message is eventually delivered and begins processing. 14. Click Stop. 15. Observe that Stop is accepted. ### Attachment crash reproduction 1. Open a conversation associated with the SSH remote. 2. Attach two local text files with a combined size of approximately 100 KB. 3. Wait for the attachments to complete uploading. 4. Click Send. 5. Observe that the turn does not visibly enter Thinking or Reasoning. 6. Observe memory increasing into multiple gigabytes, in one reproduction reaching approximately 10 GB. 7. The Windows application exits silently. ### What is the expected behavior? A single click on Send should immediately produce an authoritative and visible state: - submitted and running; - explicitly queued behind a real active turn; - or failed with an actionable error. The Send button must not become available again while the original submission may still be pending or capable of being delivered later. Windows Desktop and Android should converge promptly on the same message, queue, and active-turn state. Restarting the Windows app should not be required to make a previously submitted message appear and begin processing. Memory usage should remain bounded during submission and synchronization. ### Additional information This issue currently makes Windows Desktop unsafe and unreliable for SSH remote work. The ambiguous delivery state can cause users to resend prompts that were already accepted or recoverable. If those prompts modify files, create commits, deploy software, delete data, or perform other external actions, delayed duplicate delivery may cause conflicting or repeated operations. Windows Desktop is specifically needed in this workflow to attach local files to remote conversations. The immediate workaround is to: - upload files separately through SCP or SFTP; and - control the same remote conversation through ChatGPT on Android. However, this workaround is not operationally equivalent in all workflows. For example, I have developed a complex safety-sensitive procedure whose reviewed execution plan explicitly requires files to be attached through the Windows Desktop client at defined stages. Replacing that attachment path with SCP/SFTP and mobile control changes the procedure itself. I therefore cannot safely assume that the modified workflow preserves the same guarantees without revising the plan and repeating its independent reviews. That would require substantial additional time and paid model usage, even though neither the underlying task nor the files have changed. More generally, users with reviewed, audited, or tightly specified agent workflows may not be able to substitute a different transport path without revalidating the entire procedure.", "url": "https://github.com/openai/codex/issues/38055", "createdAt": "2026-08-11T19:07:30Z", "updatedAt": "2026-08-13T14:11:52Z", "timestamp": "2026-08-13T14:11:52Z", "metrics": { "reactions": 0, "comments": 3 }, "labels": [ "bug", "windows-os", "app", "remote", "performance" ], "author": "OlegKnyaginin", "state": "open", "assignees": [] }, { "id": "github:openai/codex:issue:38088", "source": "github", "group": "coding-agent-infrastructure", "project": "openai/codex", "kind": "issue", "title": "Webview never starts when a system proxy (VeePN/privoxy) is active — 30s startup timeout fires, \"Codex could not start\"", "text": "### What version of the IDE extension are you using? openai.chatgpt version 26.803.41515 (latest) ### What subscription do you have? plus ### Which IDE are you using? vs code ### What platform is your computer? Microsoft Windows NT 10.0.26200.0 x64 ### What issue are you seeing? The Codex sidebar webview fails to start whenever a system HTTP proxy is running (in my case the VeePN VPN, which registers privoxy as the Windows system proxy at 127.0.0.1:8080). The extension logs Webview did not finish starting and replaces the UI with the Codex could not start fallback page, even though the webview does eventually load if given enough time. Environment OS: Windows 10/11 VS Code: (add your version) Extension: openai.chatgpt version 26.803.41515 (latest) System proxy: VeePN VPN with local privoxy proxy (ProxyServer=127.0.0.1:8080, ProxyEnable=1) Without the proxy running, the webview starts fine. Steps to reproduce Enable a system HTTP proxy (e.g. VeePN/privoxy) so ProxyEnable=1 and ProxyServer=127.0.0.1:8080. Open VS Code, open the Codex sidebar. Wait ~30 seconds. The sidebar shows the Codex could not start error page. Expected behavior The Codex webview should load normally regardless of whether a system proxy is configured, or the startup timeout should be long enough (or non-blocking) so a slow but successful load isn't killed. Actual behavior After ~30s the extension log shows: Webview did not finish starting extensionVersion=26.803.41515 role=sidebar The webview is replaced with fallback HTML (default-src 'none', \"Codex could not start\"). Observed mount times when the proxy is active: routes mounted at ~26.7s / 30.1s (still flagged as failed), and in one session at ~3.5 min. With no proxy, routes mount in ~9s. Additional notes / suspected cause The extension's webview readiness timeout is hard-coded to 30 seconds (the XP class in out/extension.js uses setTimeout(..., 3e4)). The webview only sends the ready message after its initial app data queries resolve (app routes mounted log). Through the system proxy those queries take much longer (30s to 3+ minutes), so the 30s timer fires first, disposes the load, and swaps in the fallback page. Manually extending that timeout to 10 minutes (6e5) makes the webview start reliably even with the proxy active. The webview appears to block startup on network-backed queries instead of rendering with local/cached state and loading data in the background. Logs Failure (2026-08-11 session, exthost window log): `` [CodexWebviewProvider] Webview did not finish starting extensionVersion=26.803.41515 role=sidebar `` Webview renderer (successful-but-too-slow case): `` [statsig-refresh-diagnostics] React root render requested [startup][renderer] app routes mounted after 26700ms `` Suggested fix Please consider: 1.Raising the webview startup timeout well above 30s (or removing the hard timeout and relying on the ready handshake). 2.Not replacing the webview content with the \"could not start\" fallback when the load is merely slow. 3.Making the initial data queries non-blocking / fail-fast so the UI mounts with cached or empty state and hydrates in the background. ### What steps can reproduce the bug? you just need a slow proxy ### What is the expected behavior? _No response_ ### Additional information _No response_", "url": "https://github.com/openai/codex/issues/38088", "createdAt": "2026-08-11T23:40:35Z", "updatedAt": "2026-08-13T13:08:29Z", "timestamp": "2026-08-13T13:08:29Z", "metrics": { "reactions": 0, "comments": 2 }, "labels": [ "bug", "windows-os", "extension", "connectivity", "performance" ], "author": "mongo-driver", "state": "closed", "assignees": [] }, { "id": "github:openai/codex:issue:38120", "source": "github", "group": "coding-agent-infrastructure", "project": "openai/codex", "kind": "issue", "title": "Detailed transcript view in codex.", "text": "### What variant of Codex are you using? Macos app ### What feature would you like to see? Desktop does not render reasoning summaries even though summary events reach the visible renderer. [10723](https://github.com/openai/codex/issues/10723#issuecomment-5187258864) closed with \"Desktop supports live and retained reasoning summaries\" but I cannot see it. ### Environment - macOS - Codex Desktop `26.730.61639` - Build `6234` - Model: `gpt-5.6-sol` - Reasoning effort: `ultra` - `model_reasoning_summary = \"detailed\"` - `model_verbosity = \"high\"` ### What I see During a task, the conversation shows assistant messages and collapsed tool activity such as “Read files” or “Ran commands.” It does not show any live reasoning summaries, and there are no retained summaries to expand or review afterward. ### Diagnostics The Desktop logs for the affected task show all of the following: - `concurrent_reasoning_summaries` is enabled - the turn starts with `summary=detailed` - `concurrentReasoningSummariesFeatureOverrideEnabled=true` - nonempty reasoning-summary parts are received - the summary items are completed - the primary renderer is visible The logs include generated summary titles such as: - `Planning GitHub issue review` - `Verifying installed app version and update status` - `Verifying feature enablement and closure` None of those summaries are visible in the conversation. This suggests that summary generation and event delivery are working, but the Desktop renderer is not displaying the events. ### Additional information _No response_", "url": "https://github.com/openai/codex/issues/38120", "createdAt": "2026-08-12T04:48:27Z", "updatedAt": "2026-08-13T02:21:18Z", "timestamp": "2026-08-13T02:21:18Z", "metrics": { "reactions": 0, "comments": 1 }, "labels": [ "bug", "enhancement", "app" ], "author": "ShivanshuPurohit", "state": "open", "assignees": [] }, { "id": "github:openai/codex:issue:38123", "source": "github", "group": "coding-agent-infrastructure", "project": "openai/codex", "kind": "issue", "title": "[Linux Desktop 26.803.81509] Opening Git-backed Codex threads crashes the app with SIGILL in git worker", "text": "### What version of the Codex App are you using? 26.803.81509 (`x86_64-linux`) ### What subscription do you have? ChatGPT Plus ### What platform is your computer? ```text Linux 7.1.7 x86_64 unknown ``` - NixOS `26.11.20260807.afb4584` - Cinnamon desktop - X11 session ### What issue are you seeing? The app launches, authenticates, and remains stable when using regular ChatGPT conversations. However, opening an existing local Codex thread associated with a Git repository causes the entire desktop app to exit without displaying an error. I reproduced the thread-opening crash twice: 1. Opening the current local Codex thread for the repository crashed the app. 2. After relaunching, opening a different previous Codex thread for the same repository crashed it again. There were three `SIGILL` coredumps in total during testing. The additional crash occurred during an earlier Browser Use startup test and had the same native Git-worker signature. For the controlled thread-opening reproductions: - The crashing native thread was named `git`. - The last relevant application log line was: ```text [git-repo-watcher] Starting git repo watcher ``` - The main `ChatGPT` process received `SIGILL`. - Disassembly at the fault location showed `ud1`, consistent with an intentional Chromium/Node trap rather than an unsupported CPU instruction. - No OOM condition was recorded. The application was tested from OpenAI's official Linux `.deb` through the Nixpkgs packaging proposed in NixOS/nixpkgs#551713. That package currently has a separate outer-wrapper bug involving literal Wayland arguments. The Codex-thread crash still reproduced when launching through the package's internal launcher and bypassing those outer-wrapper arguments, so that wrapper bug is not required to trigger this crash. ### What steps can reproduce the bug? 1. Launch Codex/ChatGPT Desktop `26.803.81509` on Linux. 2. Sign in. 3. Open and use a regular ChatGPT conversation; the app remains stable. 4. Select an existing local Codex thread whose workspace is a Git repository. 5. The entire desktop process exits without a user-facing error. 6. Relaunch the app and select another local Codex thread for the same repository. 7. The app exits again with the same `SIGILL` Git-worker signature. ### What is the expected behavior? The local Codex thread should open normally. If Git repository discovery or watcher initialization fails, the error should be isolated and reported without terminating the entire desktop application. ### Additional information The following existing reports appear related at a high level but do not match this reproduction closely enough to treat them as confirmed duplicates: - #27614 reports a conversation-loading crash on an older Fedora Linux build, but does not include the `SIGILL` or Git-worker signature. - #35179 is specifically a Windows Desktop report with a different native exception and a later thread-memory hypothesis. - #36027 and #33042 involve the VS Code extension rather than the native Linux desktop app. The systemd coredumps have been retained locally. I can provide further sanitized metadata or disassembly details if maintainers request them through an appropriate channel.", "url": "https://github.com/openai/codex/issues/38123", "createdAt": "2026-08-12T05:06:31Z", "updatedAt": "2026-08-12T23:42:08Z", "timestamp": "2026-08-12T23:42:08Z", "metrics": { "reactions": 0, "comments": 1 }, "labels": [ "bug", "app", "session" ], "author": "nv2k", "state": "closed", "assignees": [] }, { "id": "github:openai/codex:issue:38144", "source": "github", "group": "coding-agent-infrastructure", "project": "openai/codex", "kind": "issue", "title": "/fork leaves parent thread with active writer, preventing resume in another terminal", "text": "### What version of Codex CLI is running? codex-cli 0.147.0 ### What subscription do you have? Pro ### Which model were you using? gpt-5.6-sol ### What platform is your computer? Linux 5.15.167.4-microsoft-standard-WSL2 x86_64 x86_64 ### What terminal emulator and version are you using (if applicable)? WSL ### Codex doctor report ```json { \"schemaVersion\": 1, \"generatedAt\": \"1786518424s since unix epoch\", \"overallStatus\": \"warning\", \"codexVersion\": \"0.147.0\", \"checks\": { \"app_server.status\": { \"id\": \"app_server.status\", \"category\": \"app-server\", \"status\": \"ok\", \"summary\": \"background server is not running\", \"details\": { \"control socket\": \"/home/[REDACTED_USER]/.codex/app-server-control/app-server-control.sock\", \"daemon state dir\": \"/home/[REDACTED_USER]/.codex/app-server-daemon\", \"mode\": \"ephemeral\", \"pid file\": \"/home/[REDACTED_USER]/.codex/app-server-daemon/app-server.pid (missing)\", \"settings\": \"/home/[REDACTED_USER]/.codex/app-server-daemon/settings.json (missing)\", \"status\": \"not running\", \"update-loop pid file\": \"/home/[REDACTED_USER]/.codex/app-server-daemon/app-server-updater.pid (missing)\" }, \"remediation\": null, \"durationMs\": 0 }, \"auth.credentials\": { \"id\": \"auth.credentials\", \"category\": \"auth\", \"status\": \"ok\", \"summary\": \"auth is configured\", \"details\": { \"auth env vars present\": \"OPENAI_API_KEY\", \"auth file\": \"/home/[REDACTED_USER]/.codex/auth.json\", \"auth storage mode\": \"File\", \"stored API key\": \"false\", \"stored ChatGPT tokens\": \"true\", \"stored agent identity\": \"[REDACTED: identity metadata]\", \"stored auth mode\": \"chatgpt\" }, \"remediation\": null, \"durationMs\": 0 }, \"config.load\": { \"id\": \"config.load\", \"category\": \"config\", \"status\": \"ok\", \"summary\": \"config loaded\", \"details\": { \"CODEX_HOME\": \"/home/[REDACTED_USER]/.codex\", \"config.toml\": \"/home/[REDACTED_USER]/.codex/config.toml\", \"config.toml parse\": \"ok\", \"cwd\": \"/home/[REDACTED_USER]/code/ai-content-pipeline\", \"enabled feature flags\": \"shell_tool, view_image, unified_exec, shell_snapshot, code_mode_host, terminal_resize_reflow, sqlite, memories, hooks, enable_request_compression, network_proxy, multi_agent, apps, tool_search_always_defer_mcp_tools, tool_suggest, plugins, in_app_browser, in_app_updates, browser_use, browser_use_full_cdp_access, browser_use_external, computer_use, remote_plugin, plugin_sharing, image_generation, resize_all_images, item_ids, skill_mcp_dependency_install, skill_search, mentions_v2, steer, guardian_approval, goals, collaboration_modes, tool_call_mcp_elicitation, auth_elicitation, personality, fast_mode, tui_app_server, remote_compaction_v2, workspace_dependencies\", \"feature flag overrides\": \"memories=true, network_proxy=true\", \"feature flags enabled\": \"41\", \"log dir\": \"/home/[REDACTED_USER]/.codex/log\", \"mcp servers\": \"[REDACTED: MCP server names]\", \"model\": \"gpt-5.6-sol\", \"model provider\": \"openai\", \"sqlite home\": \"/home/[REDACTED_USER]/.codex\" }, \"remediation\": null, \"durationMs\": 0 }, \"git.environment\": { \"id\": \"git.environment\", \"category\": \"git\", \"status\": \"ok\", \"summary\": \"git version 2.43.0\", \"details\": { \".git entry\": \"[REDACTED: repository metadata]\", \"PATH git #1\": \"/usr/bin/git\", \"PATH git #2\": \"/bin/git\", \"PATH git entries\": \"2\", \"git branch\": \"[REDACTED: branch name]\", \"git build options\": \"git version 2.43.0; cpu: x86_64; no commit associated with this build; sizeof-long: 8; sizeof-size_t: 8; shell-path: /bin/sh\", \"git exec path\": \"/usr/lib/git-core\", \"git version\": \"git version 2.43.0\", \"repo detected\": \"true\", \"repo root\": \"[REDACTED: repository path]\", \"selected git\": \"/usr/bin/git\" }, \"remediation\": null, \"durationMs\": 79 }, \"installation\": { \"id\": \"installation\", \"category\": \"install\", \"status\": \"ok\", \"summary\": \"installation looks consistent\", \"details\": { \"PATH codex #1\": \"/home/[REDACTED_USER]/.local/bin/codex\", \"PATH codex #2\": \"/home/[REDACTED_USER]/.local/bin/codex\", \"PATH codex #3\": \"/home/[REDACTED_USER]/.local/bin/codex\", \"PATH codex #4\": \"/home/[REDACTED_USER]/.local/bin/codex\", \"PATH codex #5\": \"/home/[REDACTED_USER]/.local/bin/codex\", \"PATH codex #6\": \"/home/[REDACTED_USER]/.local/bin/codex\", \"PATH codex #7\": \"/mnt/c/nvm4w/nodejs/codex\", \"PATH codex #8\": \"/mnt/c/nvm4w/nodejs/codex\", \"PATH codex entries\": \"8\", \"current executable\": \"/home/[REDACTED_USER]/.codex/packages/standalone/releases/0.147.0-x86_64-unknown-linux-musl/bin/codex\", \"install context\": \"standalone (unix, package /home/[REDACTED_USER]/.codex/packages/standalone/releases/0.147.0-x86_64-unknown-linux-musl, bin /home/[REDACTED_USER]/.codex/packages/standalone/releases/0.147.0-x86_64-unknown-linux-musl/bin, resources /home/[REDACTED_USER]/.codex/packages/standalone/releases/0.147.0-x86_64-unknown-linux-musl/codex-resources, path /home/[REDACTED_USER]/.codex/packages/standalone/releases/0.147.0-x86_64-unknown-linux-musl/codex-path)\", \"managed by bun\": \"false\", \"managed by npm\": \"false\", \"managed by pnpm\": \"false\", \"managed package root\": \"not set\" }, \"remediation\": null, \"durationMs\": 23 }, \"mcp.config\": { \"id\": \"mcp.config\", \"category\": \"mcp\", \"status\": \"ok\", \"summary\": \"MCP configuration is locally consistent\", \"details\": { \"configured servers\": \"[REDACTED: MCP server names]\", \"disabled servers\": \"[REDACTED: MCP server names]\", \"stdio servers\": \"[REDACTED: MCP server names]\", \"streamable_http servers\": \"[REDACTED: MCP server names]\" }, \"remediation\": null, \"durationMs\": 3481 }, \"network.env\": { \"id\": \"network.env\", \"category\": \"network\", \"status\": \"ok\", \"summary\": \"network-related environment looks readable\", \"details\": { \"proxy env vars\": \"[REDACTED: proxy configuration]\" }, \"remediation\": null, \"durationMs\": 0 }, \"network.provider_reachability\": { \"id\": \"network.provider_reachability\", \"category\": \"reachability\", \"status\": \"ok\", \"summary\": \"active provider endpoints are reachable over HTTP\", \"details\": { \"openai API base URL\": \"https://api.openai.com/v1 reachable (HTTP 404)\", \"openai API route probe\": \"https://api.openai.com/v1/ route exists (HTTP 401)\", \"reachability mode\": \"API key auth\" }, \"remediation\": null, \"durationMs\": 682 }, \"network.websocket_reachability\": { \"id\": \"network.websocket_reachability\", \"category\": \"websocket\", \"status\": \"ok\", \"summary\": \"Responses WebSocket handshake succeeded\", \"details\": { \"DNS\": \"[REDACTED: DNS result]\", \"auth mode\": \"chatgpt\", \"connect timeout\": \"15000 ms\", \"endpoint\": \"wss://chatgpt.com/backend-api/\", \"handshake result\": \"HTTP 101 Switching Protocols\", \"model provider\": \"openai\", \"models etag present\": \"true\", \"provider name\": \"OpenAI\", \"proxy env vars\": \"[REDACTED: proxy configuration]\", \"reasoning header\": \"false\", \"server model present\": \"false\", \"supports websockets\": \"true\", \"wire API\": \"responses\" }, \"remediation\": null, \"durationMs\": 1620 }, \"runtime.provenance\": { \"id\": \"runtime.provenance\", \"category\": \"runtime\", \"status\": \"ok\", \"summary\": \"running standalone on linux-x86_64\", \"details\": { \"commit\": \"unknown\", \"current executable\": \"/home/[REDACTED_USER]/.codex/packages/standalone/releases/0.147.0-x86_64-unknown-linux-musl/bin/codex\", \"install method\": \"standalone (unix, package /home/[REDACTED_USER]/.codex/packages/standalone/releases/0.147.0-x86_64-unknown-linux-musl, bin /home/[REDACTED_USER]/.codex/packages/standalone/releases/0.147.0-x86_64-unknown-linux-musl/bin, resources /home/[REDACTED_USER]/.codex/packages/standalone/releases/0.147.0-x86_64-unknown-linux-musl/codex-resources, path /home/[REDACTED_USER]/.codex/packages/standalone/releases/0.147.0-x86_64-unknown-linux-musl/codex-path)\", \"platform\": \"linux-x86_64\", \"version\": \"0.147.0\" }, \"remediation\": null, \"durationMs\": 0 }, \"runtime.search\": { \"id\": \"runtime.search\", \"category\": \"search\", \"status\": \"ok\", \"summary\": \"search is OK (bundled)\", \"details\": { \"search command\": \"/home/[REDACTED_USER]/.codex/packages/standalone/releases/0.147.0-x86_64-unknown-linux-musl/codex-path/rg\", \"search command readiness\": \"file exists\", \"search provider\": \"bundled\" }, \"remediation\": null, \"durationMs\": 0 }, \"sandbox.helpers\": { \"id\": \"sandbox.helpers\", \"category\": \"sandbox\", \"status\": \"ok\", \"summary\": \"sandbox configuration is readable\", \"details\": { \"approval policy\": \"OnRequest\", \"codex-linux-sandbox helper\": \"/home/[REDACTED_USER]/.codex/tmp/[REDACTED]\", \"execve wrapper helper\": \"/home/[REDACTED_USER]/.codex/tmp/[REDACTED]\", \"filesystem sandbox\": \"restricted\", \"network sandbox\": \"restricted\" }, \"remediation\": null, \"durationMs\": 0 }, \"state.paths\": { \"id\": \"state.paths\", \"category\": \"state\", \"status\": \"ok\", \"summary\": \"state paths and databases are inspectable\", \"details\": { \"CODEX_HOME\": \"/home/[REDACTED_USER]/.codex (dir)\", \"active rollout files\": \"1404 files, 1578995851 total bytes, 1124640 average bytes\", \"archived rollout files\": \"0 files, 0 total bytes, 0 average bytes\", \"goals DB\": \"/home/[REDACTED_USER]/.codex/goals_1.sqlite (file)\", \"goals DB integrity\": \"ok\", \"log DB\": \"/home/[REDACTED_USER]/.codex/logs_2.sqlite (file)\", \"log DB integrity\": \"ok\", \"log dir\": \"/home/[REDACTED_USER]/.codex/log (dir)\", \"memories DB\": \"/home/[REDACTED_USER]/.codex/memories_1.sqlite (file)\", \"memories DB integrity\": \"ok\", \"queue DB\": \"/home/[REDACTED_USER]/.codex/queue_1.sqlite (file)\", \"queue DB integrity\": \"ok\", \"sqlite home\": \"/home/[REDACTED_USER]/.codex (dir)\", \"standalone release cache\": \"3 entries in /home/[REDACTED_USER]/.codex/packages/standalone/releases\", \"state DB\": \"/home/[REDACTED_USER]/.codex/state_5.sqlite (file)\", \"state DB integrity\": \"ok\", \"thread history DB\": \"/home/[REDACTED_USER]/.codex/thread_history_1.sqlite (file)\", \"thread history DB integrity\": \"ok\" }, \"remediation\": null, \"durationMs\": 4889 }, \"state.rollout_db_parity\": { \"id\": \"state.rollout_db_parity\", \"category\": \"threads\", \"status\": \"warning\", \"summary\": \"rollout files and state DB thread inventory differ\", \"details\": { \"default model provider\": \"openai\", \"rollout DB active files\": \"1400\", \"rollout DB active rows\": \"1395\", \"rollout DB archive mismatches\": \"0\", \"rollout DB archived files\": \"0\", \"rollout DB archived rows\": \"0\", \"rollout DB duplicate DB paths\": \"0\", \"rollout DB duplicate rollout thread ids\": \"0\", \"rollout DB malformed file names\": \"0\", \"rollout DB missing active rows\": \"5\", \"rollout DB missing active sample\": [ \"[REDACTED: rollout path and identifier]\" ], \"rollout DB missing archived rows\": \"0\", \"rollout DB model providers\": \"openai=1395\", \"rollout DB rows\": \"1395\", \"rollout DB scan cap reached\": \"false\", \"rollout DB scan error sample\": [ \"[REDACTED: rollout path and identifier]\" ], \"rollout DB scan errors\": \"4\", \"rollout DB sources\": \"cli=448, subagent:thread_spawn=407, vscode=340, subagent:review=188, exec=12\", \"rollout DB stale rows\": \"0\" }, \"issues\": [ { \"severity\": \"warning\", \"cause\": \"rollout files are missing from the state DB\", \"measured\": \"5 active, 0 archived\", \"expected\": \"every rollout file has a matching threads row\", \"remedy\": null, \"fields\": [] }, { \"severity\": \"warning\", \"cause\": \"rollout scan was incomplete or found bad files\", \"measured\": \"4 scan errors, 0 malformed names, scan cap reached: false\", \"expected\": \"rollout directories are fully scannable\", \"remedy\": \"Check file permissions and unexpected files under CODEX_HOME sessions.\", \"fields\": [] } ], \"remediation\": null, \"durationMs\": 988 }, \"system.environment\": { \"id\": \"system.environment\", \"category\": \"system\", \"status\": \"ok\", \"summary\": \"OS language C\", \"details\": { \"EDITOR\": \"not set\", \"LANG\": \"C.UTF-8\", \"VISUAL\": \"not set\", \"os\": \"Ubuntu 24.4.0 (noble) [64-bit]\", \"os language\": \"C\", \"os type\": \"Ubuntu\", \"os version\": \"24.4.0\" }, \"remediation\": null, \"durationMs\": 4 }, \"terminal.env\": { \"id\": \"terminal.env\", \"category\": \"terminal\", \"status\": \"ok\", \"summary\": \"terminal metadata was detected\", \"details\": { \"COLORTERM\": \"truecolor\", \"DISPLAY\": \"[REDACTED: local display endpoint]\", \"TERM_PROGRAM\": \"vscode\", \"VSCODE_IPC_HOOK_CLI\": \"[REDACTED: local IPC path]\", \"WAYLAND_DISPLAY\": \"[REDACTED: local display endpoint]\", \"WSL_DISTRO_NAME\": \"present\", \"WSL_INTEROP\": \"[REDACTED: local IPC path]\", \"color output\": \"enabled\", \"effective locale\": \"C.UTF-8\", \"stderr is terminal\": \"true\", \"stdin is terminal\": \"true\", \"stdout is terminal\": \"true\", \"terminal\": \"VS Code\", \"terminal size\": \"306x37\", \"terminal version\": \"1.132.1\" }, \"remediation\": null, \"durationMs\": 0 }, \"terminal.title\": { \"id\": \"terminal.title\", \"category\": \"title\", \"status\": \"ok\", \"summary\": \"terminal title default\", \"details\": { \"redacted\": \"[REDACTED: terminal project metadata]\" }, \"remediation\": null, \"durationMs\": 0 }, \"updates.status\": { \"id\": \"updates.status\", \"category\": \"updates\", \"status\": \"ok\", \"summary\": \"update configuration is locally consistent\", \"details\": { \"cached latest version\": \"0.147.0\", \"check for update on startup\": \"true\", \"last checked at\": \"2026-08-12T06:19:22.738664369Z\", \"latest version\": \"0.147.0\", \"latest version status\": \"current version is not older\", \"update action\": \"standalone installer\", \"version cache\": \"/home/[REDACTED_USER]/.codex/version.json\" }, \"remediation\": null, \"durationMs\": 783 } } } ``` ### What issue are you seeing? `/fork` leaves the parent session with an active writer, so the parent session cannot be resumed in another terminal. I am using Codex CLI `0.147.0`. Steps to reproduce: 1. Start working in a Codex CLI session. 2. Run: ```text /fork ``` 3. Codex switches to a new forked session. 4. Run: ```text /status ``` The result confirms that the current TUI is attached to the new forked session: ```text Session: 019ff4b6-6708-7830-8f43-11ce2495c89f Forked from: 019ff4a0-1d4d-79a3-a456-ab7187a79d02 ``` After `/fork`, Codex also prints: ```text To continue this session, run codex resume 019ff4a0-1d4d-79a3-a456-ab7187a79d02 ``` 5. In another terminal, run exactly that command: ```bash codex resume 019ff4a0-1d4d-79a3-a456-ab7187a79d02 ``` Instead of resuming the parent session, Codex fails with: ```text Error: Failed to resume session from /home/pavel/.codex/sessions/2026/08/12/rollout-2026-08-12T11-19-21-019ff4a0-1d4d-79a3-a456-ab7187a79d02.jsonl: thread/resume failed during TUI bootstrap: thread/resume failed: thread 019ff4a0-1d4d-79a3-a456-ab7187a79d02 already has an active writer (code -32600) ``` ### What steps can reproduce the bug? Uploaded thread: 019ff4b6-6708-7830-8f43-11ce2495c89f ### What is the expected behavior? _No response_ ### Additional information _No response_", "url": "https://github.com/openai/codex/issues/38144", "createdAt": "2026-08-12T07:20:57Z", "updatedAt": "2026-08-12T22:02:35Z", "timestamp": "2026-08-12T22:02:35Z", "metrics": { "reactions": 1, "comments": 3 }, "labels": [ "bug", "CLI", "session" ], "author": "pkhafizov", "state": "open", "assignees": [] }, { "id": "github:openai/codex:issue:38157", "source": "github", "group": "coding-agent-infrastructure", "project": "openai/codex", "kind": "issue", "title": "ChatGPT Pro (20x) accounts appear to receive Pro 5x Codex usage capacity", "text": "### What happened? Multiple active ChatGPT Pro accounts still show the paid Pro (20x) subscription, and the official Codex usage API continues to identify them as `plan_type: \"pro\"`. However, their effective Codex usage allowance now behaves like the much smaller Pro 5x tier. The issue is therefore not the displayed subscription name or the `plan_type` field. It is the amount of usable quota actually allocated to accounts that are still subscribed to Pro (20x). ### Observed behavior - The affected accounts remain active ChatGPT Pro subscriptions. - The official usage response still reports `plan_type: \"pro\"`. - Despite that, usage percentages rise and limits are reached at a level consistent with Pro 5x rather than the expected Pro 20x allowance. - This was observed across multiple separately subscribed Pro accounts, not just one account. - The change appeared at roughly the same time across the affected accounts. ### Expected behavior Accounts subscribed to ChatGPT Pro (20x) should receive the corresponding Pro 20x Codex usage allowance. ### Actual behavior The accounts are labeled and authenticated as Pro, but their effective Codex quota appears to be provisioned at approximately the Pro 5x level. ### Request Could the team please investigate the effective quota allocation for active Pro subscriptions, including whether some Pro 20x accounts were accidentally assigned the lower 5x allowance during a quota reset or entitlement rollout? No account identifiers, email addresses, credentials, or private infrastructure details are included in this report.", "url": "https://github.com/openai/codex/issues/38157", "createdAt": "2026-08-12T09:48:12Z", "updatedAt": "2026-08-13T09:30:29Z", "timestamp": "2026-08-13T09:30:29Z", "metrics": { "reactions": 2, "comments": 2 }, "labels": [ "bug", "auth", "rate-limits" ], "author": "Jonesau", "state": "open", "assignees": [] }, { "id": "github:openai/codex:issue:38162", "source": "github", "group": "coding-agent-infrastructure", "project": "openai/codex", "kind": "issue", "title": "ChatGPT Desktop: local MCP tools are discovered successfully but not exposed to Chat sessions", "text": "### What version of the Codex App are you using (From “About Codex” dialog)? 26.803.10989.0 ### What subscription do you have? ChatGPT Plus ### What platform is your computer? Microsoft Windows NT 10.0.26100.0 x64 ### What issue are you seeing? ChatGPT Desktop successfully starts a configured local MCP server, completes the MCP initialization handshake, calls `tools/list`, and receives the full tool inventory. However, those tools are not exposed to the Chat session. The affected MCP server is configured as `tessl_registry_mcp`. The prompt used in a new Chat session was: > Use the tessl_registry_mcp MCP server and list its tools. ChatGPT responded: > I still cannot see tessl_registry_mcp in this ChatGPT session. > I checked the currently exposed connector/tool namespaces, and they are: > GitHub, Gmail, REDACTED. > tessl_registry_mcp is not among them, so I can't invoke it or enumerate its tools from here. However, a transparent stdio capture shim placed between ChatGPT Desktop and the MCP server shows that Desktop successfully: 1. launches the MCP server; 2. sends `initialize`; 3. receives a valid `initialize` response; 4. sends `notifications/initialized`; 5. sends `tools/list`; and 6. receives the server's complete 17-tool inventory. This was reproduced across three separate MCP server processes created during the same ChatGPT Desktop reproduction. The MCP server returned these tools: - `install` - `login` - `new_plugin` - `outdated` - `review_fix` - `review_run` - `review_view` - `search` - `skill_publish` - `skills_available` - `status` - `tile_publish` - `uninstall` - `update` - `workspace_create` - `workspace_list` - `workspace_list_members` ChatGPT Desktop also called `resources/list` and `resources/templates/list`. The server returned normal JSON-RPC `Method not found` responses for those methods because it does not advertise MCP resources. There was no MCP initialization or tool-discovery error in the captured exchange. This appears to be a failure after successful MCP tool discovery, in the path that registers/exposes locally discovered MCP tools to the Chat session. ### What steps can reproduce the bug? 1. On Windows 11, configure the following local MCP server in ChatGPT/Codex Desktop: - Name: `tessl_registry_mcp` - Command: `C:\\Windows\\System32\\wsl.exe` - Arguments: - `/mnt/c/Users//AppData/Local/Programs/Tessl/tessl.exe` - `mcp` - `start` Tessl version used: `0.95.0`. 2. For diagnostic purposes, place a transparent stdio shim between Desktop and the above command. The shim only forwards stdin/stdout unchanged while recording: - client -> MCP server traffic; - MCP server -> client traffic; and - MCP server stderr. 3. Fully exit and restart ChatGPT Desktop. 4. Open a new Chat session. 5. Send: `Use the tessl_registry_mcp MCP server and list its tools.` 6. Observe that Chat reports that `tessl_registry_mcp` is not present in its exposed tool namespaces. 7. Inspect the MCP shim capture. The captured protocol exchange shows: `ChatGPT Desktop -> MCP server` - `initialize` - `notifications/initialized` - `tools/list` - `resources/list` - `resources/templates/list` `MCP server -> ChatGPT Desktop` - successful `initialize` result; - successful `tools/list` result containing all 17 Tessl tools; - `Method not found` for the two resource methods. 8. Repeat the test. In my reproduction, three MCP processes were launched and all three successfully initialized and returned the full `tools/list` result. As a control test, I configured the same server through the same shim and launched it from Codex CLI `0.147.0-alpha.6.6`. The Codex CLI test succeeds: the MCP server initializes and its 17 tools are available. Therefore the same MCP server, command, transport and shim work from Codex CLI but the successfully discovered tools are not exposed to Chat in ChatGPT Desktop. Session/conversation/request identifiers in the attached public logs have been redacted. Token usage and context-window usage do not appear relevant to the reproduction. ### What is the expected behavior? After ChatGPT Desktop successfully initializes a configured MCP server and receives a successful `tools/list` response, those MCP tools should be registered and made available to the Chat session. For this server, after discovery succeeds, Chat should be able to invoke the 17 tools returned by `tessl_registry_mcp`, or at minimum recognize that the MCP server and its tools are available. Instead, Chat reports that the server is not exposed to the session even though the Desktop-side MCP client has already discovered its tools successfully. ### Additional information ### Control test The same MCP server was tested through the same transparent shim using Codex CLI `0.147.0-alpha.6.6`. That test succeeds and exposes the full 17-tool inventory. This strongly suggests that: - the MCP server itself is working; - the stdio transport is working; - the `initialize` handshake is working; - `tools/list` is working; and - the failure occurs after MCP discovery, specifically in the Desktop Chat tool-registration/exposure path. ### MCP server details Tessl CLI version: `0.95.0` Server reports: - Name: `Tessl Registry MCP` - Version: `0.0.1` - MCP protocol version: `2025-06-18` The command used during the captured Desktop reproduction was: `C:\\Windows\\System32\\wsl.exe /mnt/c/Users//AppData/Local/Programs/Tessl/tessl.exe mcp start` Note that this invokes the Windows Tessl executable through WSL interoperability; it is not a Linux-native Tessl binary. ### Desktop/app-server observations The attached Desktop log covers the same reproduction. It shows successful `mcpServerStatus/list` calls at the app-server RPC layer with `errorCode=null`. The Desktop app-server also starts normally and reports version: `0.147.0-alpha.6.6` There is an unrelated warning in the log: `ignoring invalid experimental feature enablement keys: apps_mcp_path_override` The app remains in the connected state despite that warning. There are also unrelated HTTP `429 Too many requests` warnings later in the session. The MCP initialization and tool discovery had already completed successfully before those occurred. ### Attachment glossary The uploaded diagnostic files are: #### [codex-desktop-redacted-20260812-190756.log](https://github.com/user-attachments/files/30976068/codex-desktop-redacted-20260812-190756.log) Redacted ChatGPT/Codex Desktop application log covering the reproduction. User paths, conversation/session identifiers, request IDs and named-pipe identifiers have been redacted. Timestamps, method names, feature flags, versions and diagnostic messages have been preserved. #### [ChatGPT Desktop MCP shim capture.zip](https://github.com/user-attachments/files/30976157/ChatGPT.Desktop.MCP.shim.capture.zip) One complete capture directory from the failing ChatGPT Desktop reproduction. It contains: - `command.txt` — exact working directory and child command launched by the shim. - `desktop-to-tessl.bin` — raw bytes sent by ChatGPT Desktop's MCP client to Tessl. - `tessl-to-desktop.bin` — raw bytes returned by Tessl to ChatGPT Desktop. - `tessl-stderr.log` — Tessl stderr/startup diagnostics. This capture demonstrates a successful MCP initialization and a successful `tools/list` response containing all 17 tools even though Chat subsequently reports that `tessl_registry_mcp` is unavailable. The behaviour was reproduced in three separate Desktop shim capture directories; only one complete representative capture is necessary to demonstrate the issue, but additional captures can be provided if useful. #### [Codex CLI MCP shim capture.zip](https://github.com/user-attachments/files/30976122/Codex.CLI.MCP.shim.capture.zip) Equivalent capture produced using Codex CLI as a control. This shows that the same MCP server and shim successfully initialize and expose the tools when used from Codex CLI. ### Summary The key distinction is: `MCP discovery in ChatGPT Desktop: SUCCESS` `Exposure of the discovered MCP tools to Chat: FAILURE` Because the wire-level MCP exchange succeeds, this does not appear to be a Tessl startup, WSL, stdio, handshake, or `tools/list` failure.", "url": "https://github.com/openai/codex/issues/38162", "createdAt": "2026-08-12T10:03:25Z", "updatedAt": "2026-08-13T09:53:47Z", "timestamp": "2026-08-13T09:53:47Z", "metrics": { "reactions": 0, "comments": 3 }, "labels": [ "bug", "windows-os", "mcp", "app" ], "author": "brad8898", "state": "open", "assignees": [] }, { "id": "github:openai/codex:issue:38168", "source": "github", "group": "coding-agent-infrastructure", "project": "openai/codex", "kind": "issue", "title": "Windows: hook commands with embedded quotes never execute (cmd /C outer-quote wrap in command_runner.rs) but hooks report Completed", "text": "## Environment - codex-cli 0.147.0 on Windows 11 x64 (the spawn form below is also present on current `main`) - Project hooks in `.codex/hooks.json` using `commandWindows` ## Summary On Windows, `build_command` in `codex-rs/hooks/src/engine/command_runner.rs` spawns hook commands as `cmd.exe /C \"\"` — the entire hook command line is wrapped in a literal pair of double quotes via `raw_arg` (shipped in #33926 to fix #32402). That fix covers a **leading** quoted executable path (`\"C:\\path with spaces\\hook.cmd\" notify`), but it regresses any hook command that contains an **embedded** quoted segment — for example the natural way to write a PowerShell hook: ``` powershell.exe -NoProfile -NonInteractive -Command \"\" ``` `cmd.exe` mis-parses the outer-wrapped line, so the payload never executes. Depending on the exact token stream Codex still prints `hook: Completed`, making the failure completely silent (this is very likely the mechanism behind #33564 as well). ## Minimal repro 1. Configure and trust a project `UserPromptSubmit` hook with: ```json \"commandWindows\": \"powershell.exe -NoProfile -NonInteractive -Command \\\"Set-Content -Path '%USERPROFILE%\\\\hook-canary.txt' -Value ran\\\"\" ``` 2. Trigger the event. 3. Codex reports `hook: UserPromptSubmit Completed`, but `hook-canary.txt` is never created. No spawn result, exit code, stdout, or stderr is persisted anywhere I could find. ## Exact spawn-form repro (outside Codex) This is exactly what Codex executes since #33926 (`cmd.exe /C` + `raw_arg(\"\\\"{command_line}\\\"\")`): ``` cmd.exe /C \"powershell.exe -NoProfile -NonInteractive -Command \"Set-Content -Path 'D:\\Temp\\canary.txt' -Value ran\"\" ``` Result: exit 1, `系统找不到指定的路径。` (path-not-found from cmd's mis-parse), file never created. Control cases that both work correctly: - direct spawn: `powershell.exe -NoProfile -NonInteractive -Command \"Set-Content -Path 'D:\\Temp\\canary.txt' -Value ran\"` → exit 0, file created - `cmd.exe /C` **without** the outer quote wrap: `cmd.exe /C powershell.exe -NoProfile -NonInteractive -Command \"Set-Content -Path 'D:\\Temp\\canary.txt' -Value ran\"` → exit 0, file created So the defect is specifically the outer-quote wrapping, not the command itself and not PowerShell. ## Expected behavior 1. Pass the hook command line to `cmd.exe /C` verbatim (via `raw_arg`, **without** adding an outer quote pair), or otherwise preserve embedded quotes correctly, so commands like the PowerShell form above execute as written. 2. When the hook process fails to launch or exits non-zero, do not report `Completed`; persist the spawn result, exit code, stdout, and stderr so silent no-ops are diagnosable (also requested in #33564). ## Workaround Use a quote-free, space-free command line and move all real logic into a batch file: ``` \"commandWindows\": \"cmd.exe /c C:\\\\path\\\\to\\\\hook-wrapper.cmd\" ``` Verified working end-to-end on codex-cli 0.147.0 (hook output JSON is parsed and `additionalContext` attaches correctly once the command actually executes). ## Refs - #32402 — original quoted-path failure (closed by #33926) - #33926 — introduced the outer-quote wrap that causes this embedded-quote failure - #33564 — Desktop: trusted hook \"completes\" but handler never reaches script entry; likely the same mechanism", "url": "https://github.com/openai/codex/issues/38168", "createdAt": "2026-08-12T10:35:21Z", "updatedAt": "2026-08-12T14:49:16Z", "timestamp": "2026-08-12T14:49:16Z", "metrics": { "reactions": 0, "comments": 1 }, "labels": [ "bug", "windows-os", "CLI", "hooks" ], "author": "M1nt-Ch0c0", "state": "open", "assignees": [], "change": "updated" }, { "id": "github:openai/codex:issue:38169", "source": "github", "group": "coding-agent-infrastructure", "project": "openai/codex", "kind": "issue", "title": "[CLI/TUI] thread/resume silently drops the newest turns on heavily compacted threads", "text": "### What version of Codex CLI is running? `codex-cli 0.147.0` ### What subscription do you have? ChatGPT subscription (exact tier not disclosed). ### Which model were you using? `gpt-5.6-sol` ### What platform is your computer? Windows 11 Professional, build `10.0.26200`, x64. ### What terminal emulator and version are you using? Windows Terminal, PowerShell, no terminal multiplexer. ### Codex doctor report Fresh `codex doctor --json`, summarized to exclude local paths, user names, thread identifiers, and private configuration: - `overallStatus: ok`, `codexVersion: 0.147.0`; - auth configured, ChatGPT auth mode, no stored API key; - config load `ok`; - app-server mode `ephemeral`, not running at check time. ### What issue are you seeing? On threads that have been auto-compacted many times, resuming returns **fewer turns than the rollout stores, and the turns that go missing are the newest ones**. The thread reopens several turns behind where work actually stopped, so the last thing asked and answered is not visible. This is a silent, successful resume. There is no error, no warning, and no transport failure — the response simply contains an earlier slice of the thread. The rollout on disk is complete. Verified four ways on this machine: - 0 of 105 threads in `history.jsonl` lack a rollout file; - 0 of 583 rollout files are truncated or empty; - 0 of 105 rollouts have a last user prompt older than the prompt history records; - 0 of 178 user threads have a competing second rollout file. So this is thread reconstruction on read, not data loss on write. ### What steps can reproduce the bug? 1. Use a Codex CLI thread heavily enough that it auto-compacts many times (the two affected threads here carry 33 and 26 `compacted` records). 2. Close the TUI normally. 3. Drive the app-server directly and compare stored vs returned prompts: - count `response_item` payloads with `role: \"user\"` in the thread's rollout; - call `thread/resume` with only `{\"threadId\": ...}` (the parameters the TUI sends); - count `userMessage` items across `result.thread.turns`. 4. The counts differ, and the returned tail is not the stored tail. Measured over all 11 resumable threads on this machine, `0.147.0`: | thread | `compacted` records | rollout size | prompts stored | prompts returned | % returned | |---|---:|---:|---:|---:|---:| | A | 33 | 239 MB | 41 | **8** | 20% | | B | 26 | 76 MB | 60 | **19** | 32% | | C | 20 | 68 MB | 32 | **8** | 25% | | D | 15 | 90 MB | 48 | **9** | 19% | | E | 10 | 100 MB | 16 | 15 | 94% | | F | 10 | 28 MB | 13 | 12 | 92% | | G | 5 | 24 MB | 21 | 20 | 95% | | H | 5 | 20 MB | 22 | 20 | 91% | | I | 2 | 23 MB | 19 | 18 | 95% | | J | 0 | 2 MB | 3 | 2 | 67% | | K | 0 | 2 MB | 3 | 2 | 67% | The result is bimodal with nothing in between: 19–32% versus 91–100%. The one-or-two-prompt shortfall in the healthy group is the bootstrap instruction payload, not lost history. A–D are qualitatively different — they return an early slice and stop. The separating variable is compaction count, not size: - every truncated thread has **≥ 15** `compacted` records (15, 20, 26, 33); - every intact thread has **≤ 10** (0, 0, 2, 5, 5, 10, 10). Rollout size does **not** separate them. Thread E is 100 MB and resumes intact; thread C is 68 MB and returns a quarter of its prompts. Size should not be read as the trigger. A standalone reproduction script is attached below. It reads only local files and the local app-server, prints no transcript content, and hashes each rollout before and after the call. In every run here the hashes were identical, so `thread/resume` did not mutate stored history. ### What is the expected behavior? A default `thread/resume` should return the thread through its newest completed turn, or fail loudly if it cannot. If a compacted thread cannot be fully reconstructed, the response should say so rather than returning an earlier slice that is indistinguishable from a complete one. Compaction must not make recent history unreachable to the client that is resuming. ### Additional information ### Relationship to #34663 Both concern what resume hands the client, in opposite directions. #34663 asks the TUI to render *less* on bootstrap. This asks that whatever is rendered *include the newest turn*. A fix for #34663 that pages turns must not be built on the reconstruction path measured here, or the paged view will page an already-truncated list. Note that the paging API #34663 pointed at is still unreachable from a normal client on `0.147.0`: both `thread/resume` with `initialTurnsPage` and `thread/turns/list` reject with `requires experimentalApi capability`. So the TUI does take the default full-history path, and that path is the one that truncates. ### What is not established Eleven threads on one machine is a small sample, and the boundary is only bracketed: 10 compactions intact, 15 truncated, nothing observed in between. No claim is made about the mechanism inside thread reconstruction — only the input/output behavior was measured. Whether the trigger is the compaction count itself, total compacted history, or something correlated with both is open. ### Reproduction script ```python \"\"\"Compare prompts stored in a Codex rollout against prompts returned by resume. Read-only. Prints counts and a hash check, never transcript content. Usage: python resume_truncation_repro.py \"\"\" import glob, hashlib, json, pathlib, subprocess, sys, threading, time CODEX = pathlib.Path.home() / \".codex\" TID = sys.argv[1] path = None for f in glob.glob(str(CODEX / \"sessions\" / \"**\" / \"rollout-*.jsonl\"), recursive=True): with open(f, encoding=\"utf-8\", errors=\"replace\") as fh: for line in fh: if \"session_meta\" in line: d = json.loads(line) if d.get(\"type\") == \"session_meta\" and d.get(\"payload\", {}).get(\"id\") == TID: path = f break if path: break if not path: raise SystemExit(f\"no rollout for {TID}\") stored, compactions = 0, 0 with open(path, encoding=\"utf-8\", errors=\"replace\") as fh: for line in fh: try: d = json.loads(line) except json.JSONDecodeError: continue if d.get(\"type\") == \"compacted\": compactions += 1 p = d.get(\"payload\") or {} if d.get(\"type\") == \"response_item\" and p.get(\"role\") == \"user\": text = \"\".join(c.get(\"text\", \"\") for c in (p.get(\"content\") or []) if isinstance(c, dict)).strip() if text and not text.startswith(\"<\"): stored += 1 before = hashlib.sha256(pathlib.Path(path).read_bytes()).hexdigest() proc = subprocess.Popen([\"codex\", \"app-server\"], stdin=subprocess.PIPE, stdout=subprocess.PIPE, stderr=subprocess.PIPE, text=True, encoding=\"utf-8\", errors=\"replace\", bufsize=1) replies = {} def reader(): for line in proc.stdout: line = line.strip() if not line: continue try: m = json.loads(line) except json.JSONDecodeError: continue if \"id\" in m and (\"result\" in m or \"error\" in m): replies[m[\"id\"]] = m threading.Thread(target=reader, daemon=True).start() def call(rid, method, params, wait=120): proc.stdin.write(json.dumps({\"jsonrpc\": \"2.0\", \"id\": rid, \"method\": method, \"params\": params}) + \"\\n\") proc.stdin.flush() for _ in range(wait * 10): if rid in replies: return replies[rid] time.sleep(0.1) return None call(1, \"initialize\", {\"clientInfo\": {\"name\": \"repro\", \"title\": \"repro\", \"version\": \"0\"}}) res = call(2, \"thread/resume\", {\"threadId\": TID})[\"result\"] returned = sum( 1 for turn in (res.get(\"thread\") or {}).get(\"turns\") or [] for item in turn.get(\"items\") or [] if isinstance(item, dict) and item.get(\"type\") == \"userMessage\" ) after = hashlib.sha256(pathlib.Path(path).read_bytes()).hexdigest() print(f\"compacted records : {compactions}\") print(f\"rollout size (MB) : {pathlib.Path(path).stat().st_size / 1048576:.0f}\") print(f\"prompts stored : {stored}\") print(f\"prompts returned : {returned}\") print(f\"rollout unchanged : {before == after}\") proc.stdin.close() proc.terminate() ``` ### Suggested acceptance criteria 1. For a heavily compacted thread, `thread/resume` returns turns through the newest completed turn. 2. A thread that cannot be fully reconstructed reports that explicitly instead of returning a short list silently. 3. A regression test covers a thread with many compaction records, asserting the newest turn is present in the resume response. 4. Resume continues to leave the rollout byte-identical.", "url": "https://github.com/openai/codex/issues/38169", "createdAt": "2026-08-12T10:41:29Z", "updatedAt": "2026-08-13T00:14:31Z", "timestamp": "2026-08-13T00:14:31Z", "metrics": { "reactions": 0, "comments": 2 }, "labels": [ "bug", "windows-os", "TUI", "CLI", "context", "app-server" ], "author": "wenqifu", "state": "open", "assignees": [] }, { "id": "github:openai/codex:issue:38176", "source": "github", "group": "coding-agent-infrastructure", "project": "openai/codex", "kind": "issue", "title": "Codex Renderer is consuming excessive memory", "text": "### What version of the Codex App are you using (From “About Codex” dialog)? 26.803.41515 ### What subscription do you have? ChatGPT Pro 20x ### What platform is your computer? arm64 ### What issue are you seeing? The Codex Renderer processes are consuming an excessive amount of memory. This may be related to conversations becoming very large over time. A long conversation contains a significant amount of scrollable content, and it appears that too much of this content may remain loaded or rendered in memory. Implementing more efficient list virtualization, lazy rendering, or pagination could potentially reduce the memory usage of long conversations. I am also not sure why two separate Codex Renderer processes are running at the same time, or whether both processes are contributing to the excessive memory consumption. \"Codex ### What steps can reproduce the bug? 1. Open or continue using a conversation that contains a large number of messages. 2. Scroll through the conversation or continue adding messages. 3. Check the application's memory usage in the system process monitor. 4. Observe that the Codex Renderer processes consume an excessive amount of memory. The exact conditions that trigger the issue are currently unclear. ### What is the expected behavior? Memory usage should remain within reasonable limits, even when a conversation contains a large number of messages. Content that is not currently visible should not remain fully rendered in memory unnecessarily. Additionally, the application should not run multiple renderer processes unless they are required. ### Additional information The issue appears to become more noticeable as the conversation grows longer.", "url": "https://github.com/openai/codex/issues/38176", "createdAt": "2026-08-12T12:10:56Z", "updatedAt": "2026-08-13T02:03:32Z", "timestamp": "2026-08-13T02:03:32Z", "metrics": { "reactions": 0, "comments": 2 }, "labels": [ "bug", "app", "performance" ], "author": "barisyild", "state": "open", "assignees": [] }, { "id": "github:openai/codex:issue:38180", "source": "github", "group": "coding-agent-infrastructure", "project": "openai/codex", "kind": "issue", "title": "Document rollout JSONL and correct session-search extraction", "text": "EDIT:I accidentally created an Issue via the Codex. I'll close it. Sorry about that.", "url": "https://github.com/openai/codex/issues/38180", "timestamp": "2026-08-12T12:30:09Z", "metrics": { "reactions": 0, "comments": 0 }, "labels": [ "bug", "CLI", "skills", "session", "performance" ], "author": "Rokurolize", "assignees": [], "change": "new" }, { "id": "github:openai/codex:issue:38181", "source": "github", "group": "coding-agent-infrastructure", "project": "openai/codex", "kind": "issue", "title": "Windows: adding a second root folder to a project crashes the app UI (\"process is not defined\")", "text": "### What version of the Codex App are you using (From “About Codex” dialog)? 26.721.31836 (package OpenAI.Codex_26.721.3996.0_x64, app-server 0.146.0-alpha.3.1) ### What subscription do you have? ChatGPT Pro (personal) ### What platform is your computer? Microsoft Windows NT 10.0.26200.0 x64 ### What issue are you seeing? On Windows, as soon as a project has **more than one root folder**, the renderer crashes and the app becomes unusable: instead of the UI you get the \"Oops, an error occurred\" screen with \"Update ChatGPT\" / \"Try again\". \"Try again\" re-crashes ~250 ms after `app routes mounted`, on every launch, so there is no way to reach project settings and remove the extra folder from inside the app. The first crash in my case happened 19 seconds after I added two extra folders to a project (project `updatedAt` in `.codex-global-state.json` = `2026-08-12T11:44:22.504Z`, first error boundary at `11:44:41Z`). Log (`%LOCALAPPDATA%\\Packages\\OpenAI.Codex_*\\LocalCache\\Local\\Codex\\Logs\\\\\\\\codex-desktop-*-t0-*.log`): ``` error [electron-message-handler] error boundary componentStack=\" at C3s (app://-/assets/app-initial-DVfVy4b5.js:8875:151178) at gk (app://-/assets/app-initial-DVfVy4b5.js:915:7110) ...\" errorMessage=\"process is not defined\" errorName=Error name=AppRoutes ``` The backend side is healthy — app-server handshake ok, auth ok, `GET /backend-api/codex/models` -> 200 OK. This is purely a renderer crash. ## Root cause `C3s` in `app-initial-DVfVy4b5.js` is the `thread-file-search` command-menu registration. It de-duplicates workspace roots with: ```js function TFi(e){ return e.filter((t,n)=>e.every((e,r)=>{ if (r===n) return true; // never compares when there is only 1 root let i = path.posix.relative(bf(e), bf(t)); // <-- browserify path shim return i===\"..\" || i.startsWith(\"../\") || (i===\"\" && r>n) }))} ``` The bundled `path` is the browserify shim, whose `resolve()` falls back to `process.cwd()` when no argument starts with `/`. A Windows path (`D:\\Repos\\foo`) is *never* absolute under the POSIX shim, so that branch is always taken — and `process` does not exist in the sandboxed renderer, hence `ReferenceError: process is not defined`. With a single root the inner `every` callback only ever hits `r === n` and returns early, so `relative()` is never called. That is why this breaks only at 2+ roots, and why the app worked fine for weeks before. ### What steps can reproduce the bug? On Windows: 1. Open a project with a single root folder — the app works normally. 2. Add a second folder to the same project (so `local-projects..rootPaths` in `~/.codex/.codex-global-state.json` has 2+ entries). 3. The UI crashes with the \"Oops, an error occurred\" screen, and keeps crashing on every relaunch — the selection is persisted, so the app never recovers on its own. Reproduces regardless of which folders are used, as long as there are two or more Windows paths. ### What is the expected behavior? A project with multiple root folders works on Windows the same way it does on macOS/Linux: the @-mention file search de-duplicates nested roots and the UI keeps rendering. Additionally, an error thrown while registering a command-menu entry should not take down the whole `AppRoutes` subtree — right now one throwing hook makes the entire app unreachable, with no way to undo the setting that caused it. ### Additional information **Suggested fix:** use the platform-aware `path` (`path.win32` on Windows) for that comparison, or compare normalized absolute paths without routing them through the POSIX shim's `resolve()`. Bundling a `path` shim that reaches for `process.cwd()` in a sandboxed renderer is a latent crash for every Windows code path that calls `resolve()`/`relative()` with a drive-letter path — this is just the first place it surfaced. **Workaround** (for anyone hitting this): quit all `ChatGPT.exe`, then in `~/.codex/.codex-global-state.json` reduce `local-projects..rootPaths` back to a single path — mirror the same edit into the `.bak` file next to it, since the app reads it too — and relaunch. Threads, `config.toml` and auth are unaffected. Notes: - `windows-store-updater` reports `hasUpdate=false overallState=NoUpdates`, so the \"Update ChatGPT\" button on the error screen has nothing to fetch and does not help. - Only the primary window crashes; the avatar-overlay window (webContentsId 2) renders fine. - Paths in this report are genericized.", "url": "https://github.com/openai/codex/issues/38181", "timestamp": "2026-08-12T12:45:10Z", "metrics": { "reactions": 0, "comments": 0 }, "labels": [ "bug", "windows-os", "app" ], "author": "nubick", "assignees": [], "change": "new" }, { "id": "github:openai/codex:issue:38182", "source": "github", "group": "coding-agent-infrastructure", "project": "openai/codex", "kind": "issue", "title": "[macOS] “More details” Quick Chat turns white when sending a large text input", "text": "### What version of the Codex App are you using (From “About Codex” dialog)? 26.803.81509 (build 6415) ### What subscription do you have? _Not provided_ ### What platform is your computer? macOS 26.5.2 (build 25F84), Apple Silicon (arm64) ### What issue are you seeing? In the Codex desktop app, selecting text and choosing **More details** opens the ChatGPT Quick Chat surface as expected. However, when a large amount of text is entered or pasted into that Quick Chat and sent, the surface suddenly becomes entirely white and enters an error state. The Quick Chat can no longer be used normally. This appears to occur in the ChatGPT handoff/Quick Chat opened from **More details**, rather than after adding that conversation back into the Codex task. ### What steps can reproduce the bug? 1. Open a Codex task in the macOS desktop app. 2. Select text in a message and choose **More details**. 3. In the ChatGPT Quick Chat that opens, enter or paste a large amount of text. 4. Send the message. 5. Observe that the Quick Chat surface becomes a blank white screen/error state. The exact character threshold has not yet been isolated, but the failure is associated with a large text input. ### What is the expected behavior? The Quick Chat should accept and render a large text input normally, or provide a clear, recoverable validation/error message if an input limit is exceeded. It should not become a blank white screen. ### Additional information Potentially related but distinct from #31966 and #32033: those reports describe Codex freezing when a **More details** conversation is added back to the task. This report concerns the Quick Chat itself becoming blank immediately after sending a large text input, before that return-to-task flow. A screenshot/screen recording can be provided if needed.", "url": "https://github.com/openai/codex/issues/38182", "timestamp": "2026-08-12T12:51:34Z", "metrics": { "reactions": 0, "comments": 0 }, "labels": [ "bug", "app" ], "author": "junjunjunbong", "assignees": [], "change": "new" }, { "id": "github:openai/codex:issue:38185", "source": "github", "group": "coding-agent-infrastructure", "project": "openai/codex", "kind": "issue", "title": "recommended_plugins injection has no working opt-out (feature flag removed / disable-plugins is all-or-nothing)", "text": "## Summary The `` block (list of ~38 not-installed third-party plugins, e.g. Atlassian, Airtable, HubSpot, ...) is unconditionally injected as an `input_text` item on the first user turn of every session, and there is no working client-side way to suppress it — even though a related feature-flag mechanism exists. ## Environment - `codex-cli 0.146.0` (Windows, native CLI) - Also reproduced earlier on `0.147.0-alpha.6.5` ## Steps to Reproduce (no API billing — uses local prompt rendering only) ``` codex debug prompt-input \"test\" ``` Output contains a developer/user message with: ``` \"text\": \"\\nHere is a list of plugins that are available but not installed.\\n\\n- Airtable (airtable@openai-curated-remote)\\n- Apollo.io (apollo@openai-curated-remote)\\n...\\n\" ``` ~1,900 characters / ~470 tokens, listing ~38 plugins from a remote/hardcoded catalog (`@openai-curated-remote`) that is unrelated to the local `codex plugin marketplace list` configuration. ## What I tried (all ineffective) 1. **`codex features list`** no longer even lists a `recommended_plugins` flag (it did on the alpha build tested earlier, shown as `stable false`). Running: ``` codex debug prompt-input --disable recommended_plugins \"test\" ``` now fails with `Error: Unknown feature flag: recommended_plugins`. On the earlier alpha build where the flag still existed, passing `--disable recommended_plugins` produced byte-identical output to the default run (only a random message ID differed) — i.e. the flag never actually controlled this injection path even when it was listed. 2. **`--disable plugins`** (the only remaining related flag, `stable true` by default) *does* remove the `` block, but it does so by disabling the entire plugin instruction subsystem — it also strips the `` block that documents currently-*installed and enabled* plugins. For a user with real plugins enabled (e.g. `documents`, `spreadsheets`, `chrome`, `computer-use`, `pdf`, ...), this is not usable: it silences the model's knowledge of plugins actually in use, not just the unused recommendations list. 3. **Emptying the plugin marketplace config** (`-c \"marketplaces={}\"`, process-local, non-destructive) does not change the injected list at all — confirming the list is generated from a source independent of local `[marketplaces]` config. ## Impact Because `history_mode: \"legacy\"` resends full conversation history on every API call within a session, this ~470-token block is effectively billed on every turn of the session, not just the first — a constant, unavoidable per-session tax with no opt-out. ## Expected behavior Either: - `features.recommended_plugins` (or an equivalent, currently-functional flag) actually gates this injection, independent of `features.plugins`, or - the recommendation list is omitted/trimmed after the first turn (respecting `history_mode`), or - there is a config key (e.g. `show_recommended_plugins = false`) to opt out without disabling real plugin functionality. ## Additional notes - Searched existing issues for `recommended_plugins` / \"recommended plugin injection\" and found no exact duplicate as of this report. - Happy to provide the full `codex debug prompt-input` output (local rendering, no session/user data) if useful.", "url": "https://github.com/openai/codex/issues/38185", "timestamp": "2026-08-12T13:02:26Z", "metrics": { "reactions": 0, "comments": 1 }, "labels": [ "bug", "CLI", "skills", "config" ], "author": "konomings", "assignees": [], "change": "new" }, { "id": "github:openai/codex:issue:38187", "source": "github", "group": "coding-agent-infrastructure", "project": "openai/codex", "kind": "issue", "title": "GPT-5.6 consistently aborts functions.exec / tools.exec_command, while GPT-5.5 works", "text": "### What version of Codex CLI is running? codex-cli 0.147.0 ### What subscription do you have? Enterprise ### Which model were you using? _No response_ ### What platform is your computer? _No response_ ### What terminal emulator and version are you using (if applicable)? _No response_ ### Codex doctor report ```json ``` ### What issue are you seeing? ## Summary `functions.exec` consistently returns `aborted` when running shell commands with GPT-5.6 models, while the same operation works normally with GPT-5.5. ## Reproduction Run a minimal shell command: ```sh echo hello ``` The tool call immediately returns: ```text aborted ``` No command output, stderr, or exit code is returned. The issue is reproducible with other trivial commands, including: ```sh pwd echo hello python3 --version ``` It also occurs when invoking the nested JavaScript tool: ```js const r = await tools.exec_command({ cmd: \"echo hello\", yield_time_ms: 10000, max_output_tokens: 2000 }); text(r.output); ``` The execution is still aborted before any command output is produced. ## Expected behavior The command should execute successfully and return: ```text hello ``` ## Actual behavior The execution is aborted before the command produces any output. There is no stdout, stderr, or exit code returned by the tool call. ## Model comparison * GPT-5.5: works normally * GPT-5.6: consistently returns `aborted` * GPT-5.6-terra: consistently returns `aborted` The same Codex CLI installation and environment are used for the model comparison. ## Additional observations * The failure occurs with trivial local commands that do not require network access or special permissions. * `echo hello` reproduces the issue, so the failure does not appear to be related to Python, Git, or the repository. * Changing the working directory, shell options, and command arguments does not resolve the issue. * Switching to GPT-5.5 immediately restores normal command execution. * The behavior is consistently reproducible with GPT-5.6 models. This appears to be a model-specific issue in the tool execution path rather than a failure of the underlying shell command. ## Environment * OS: macOS * Codex CLI: `0.147.0` * Tool: `functions.exec` / `tools.exec_command` * Model: GPT-5.6 / GPT-5.6-terra * Working directory: local Git repository * Architecture: Apple Silicon ## Minimal reproduction ```text Codex CLI 0.147.0 Model: GPT-5.6-terra User: Run `echo hello` Tool: functions.exec Result: aborted No stdout No stderr No exit code ``` Switching only the model: ```text Codex CLI 0.147.0 Model: GPT-5.5 User: Run `echo hello` Tool: functions.exec Result: hello ``` The difference is consistently reproducible. ### What steps can reproduce the bug? 1. Install and run Codex CLI `0.147.0` on macOS (Apple Silicon). 2. Open a local Git repository with Codex. 3. Select the `GPT-5.6-terra` model. 4. Ask Codex to execute a trivial shell command, for example: ```sh echo hello ``` 5. Observe that the `functions.exec` / `tools.exec_command` call immediately returns `aborted`. 6. No stdout, stderr, or exit code is returned. 7. Repeat with other trivial commands such as: ```sh pwd python3 --version ``` The same behavior occurs. 8. Switch the model to `GPT-5.5` and run the same commands. 9. Observe that the commands execute normally and return their expected output. ### What is the expected behavior? _No response_ ### Additional information _No response_", "url": "https://github.com/openai/codex/issues/38187", "createdAt": "2026-08-12T13:16:20Z", "updatedAt": "2026-08-13T03:44:03Z", "timestamp": "2026-08-13T03:44:03Z", "metrics": { "reactions": 0, "comments": 1 }, "labels": [ "bug", "CLI", "tool-calls" ], "author": "FPbear", "state": "open", "assignees": [] }, { "id": "github:openai/codex:issue:38190", "source": "github", "group": "coding-agent-infrastructure", "project": "openai/codex", "kind": "issue", "title": "Windows Desktop 26.803.10989.0: apply_patch hangs indefinitely while shell I/O works", "text": "### What version of the Codex App are you using (From “About Codex” dialog)? 26.803.10989.0 ### What subscription do you have? Plus ### What platform is your computer? Microsoft Windows NT 10.0.26200.0 x64 ### What issue are you seeing? On Codex Desktop for Windows, every `apply_patch` call hangs indefinitely before applying any filesystem change. This reproduces with a one-line disposable file as well as small updates to existing files. Normal shell commands can read the workspace immediately, and the workspace is configured writable. The Windows sandbox setup log reports successful setup with `errors=[]`. No patch attempt appears to reach the sandbox command-runner log. The behavior persisted after: - fully terminating all `codex*` processes - restarting the official Codex app - checking Microsoft Store for updates - disabling Comodo Auto-Containment and trusting the Codex executables - testing a minimal file in the workspace root The tool remains in a running state until manually terminated. No target file is created or modified. This appears similar to #34549, #34290, #13965/#13959, and #29365, but it still reproduces on app version 26.803.10989.0 with command runner 0.147.0-alpha.6.6. ### What steps can reproduce the bug? 1. Open the official Microsoft Store Codex Desktop app on Windows. 2. Open a writable workspace. 3. Invoke a minimal patch: ``` *** Begin Patch *** Add File: .codex-patch-test.txt +patch service test *** End Patch ``` 4. Observe that the tool remains running indefinitely. 5. Terminate the tool after 20-40 seconds. 6. Verify that `.codex-patch-test.txt` was not created. 7. Run `Test-Path .codex-patch-test.txt` or normal read commands; shell execution completes normally. Session ID: 019ff59c-6f61-75a3-8d7f-5aa18d26be9f ### What is the expected behavior? A valid one-line patch in a writable workspace should complete within a few seconds, create the file, and return a clear success result. If a helper cannot launch, the tool should fail promptly with the underlying Windows error instead of hanging. ### Additional information Installed package: `OpenAI.Codex_26.803.10989.0_x64__2p2nqsd0c76g0` Observed processes: - `codex.exe` - `codex-code-mode-host.exe` - `codex-command-runner-0.147.0-alpha.6.6.exe` The sandbox log shows setup refreshes completing successfully and the command runner being copied/reused from the packaged app. Ordinary shell access to the workspace succeeds. This strongly suggests the hang occurs in the app/tool bridge before the patch reaches filesystem execution. No WindowsApps ownership or ACL changes were made.", "url": "https://github.com/openai/codex/issues/38190", "timestamp": "2026-08-12T13:38:37Z", "metrics": { "reactions": 0, "comments": 0 }, "labels": [ "bug", "windows-os", "tool-calls", "app" ], "author": "shaynec777", "assignees": [], "change": "new" }, { "id": "github:openai/codex:issue:38191", "source": "github", "group": "coding-agent-infrastructure", "project": "openai/codex", "kind": "issue", "title": "[Desktop][macOS] 7-day usage remaining jumped from 48% to 23% after context/memory feature change", "text": "### What issue are you seeing? The Codex Desktop 7-day usage indicator appeared to drop instantly from **48% remaining to 23% remaining**, despite very little intentional use that day. Local session telemetry shows this is the primary 7-day rate limit, not the model context-window indicator: - Earlier record: `used_percent: 52.0` (48% remaining) - Current record: `used_percent: 77.0` (23% remaining) - `window_minutes: 10080` - Model context window is separately reported as 258,400 tokens The first `token_count` event in a new diagnostic task already reported `used_percent: 77.0`, before its diagnostic tool calls. Therefore the apparent 25-point drop was not caused solely by that task. It looks like stale UI state being refreshed all at once, delayed server-side accounting, or incorrect attribution. A context/memory/window-capture-related option had been enabled the previous day. Relevant observations: - Later session metadata records show `memory_mode: enabled`. - The currently persisted auto-context setting reports disabled. - The affected session record does not contain actual window-context, screen-capture, OCR, or image input items. - New turns do contain a large automatically injected payload, including plugin metadata, project instructions, skill metadata, memory guidance, and tool schemas. - In one short diagnostic session, cumulative token events progressed from approximately 29k to 61k to 104k within about 32 seconds, with a large cached-input component. The weekly meter stayed at 77% during those calls. Please investigate: 1. Whether the remaining-usage UI can remain stale and then jump when a new task starts. 2. Whether memory/context/window-capture features change quota accounting or cause repeated system/tool context injection. 3. Whether cached or automatically injected input is attributed correctly. 4. Whether the UI can distinguish weekly quota remaining from model context-window remaining and expose per-task attribution. ### Steps to reproduce 1. Enable the context/memory/window-capture-related feature. 2. Leave Codex mostly idle or perform only a small amount of intentional work. 3. Start or resume a project task. 4. Observe whether the weekly remaining-usage percentage refreshes abruptly. 5. Compare the UI with local JSONL `token_count` events. The issue may be intermittent because it appears to involve delayed refresh or accounting. ### Expected behavior - Weekly usage should update promptly enough that a 25-point change is attributable to visible activity. - Enabling memory/context support should not unexpectedly consume a large portion of the weekly quota. - Automatically injected and cached context should have transparent, correct quota treatment. - The UI should clearly label weekly quota versus current context-window capacity. ### Environment - Product: Codex Desktop on macOS - macOS: 26.5 - Architecture: arm64 - Codex backend/CLI version recorded in session metadata: `0.147.0-alpha.6.5` No local paths, account/plan details, session identifiers, private project content, or full logs are included.", "url": "https://github.com/openai/codex/issues/38191", "timestamp": "2026-08-12T13:41:47Z", "metrics": { "reactions": 0, "comments": 1 }, "labels": [ "bug", "rate-limits", "context", "app", "memory" ], "author": "anbozzz", "assignees": [], "change": "new" }, { "id": "github:openai/codex:issue:38192", "source": "github", "group": "coding-agent-infrastructure", "project": "openai/codex", "kind": "issue", "title": "/agent thread switching emits stale completion notifications during replay", "text": "### Codex version `codex-cli 0.147.0` ### Platform Linux, Ghostty, Codex running in long-lived dtach sessions. ### What issue are you seeing? Selecting a parent or child thread with `/agent` can emit a fresh terminal `AgentTurnComplete` notification for a completion that happened earlier and is merely being replayed. If the terminal notification method is OSC 9, this appears as a stale desktop popup containing an old final message. With the BEL backend, it becomes a stale tab bell instead. Changing the backend therefore mitigates the disruption but does not suppress the erroneous event. This is distinct from a real completion occurring while the selected thread is in the foreground: the notification is emitted at thread-selection/replay time, even when newer text already exists below the historical completion and the user just selected the thread manually. ### Steps to reproduce 1. Start a parent thread and let a turn finish with final message A. 2. Spawn a subagent whose thread inherits or forks the parent history. 3. Continue until newer content exists in the parent and/or child. 4. Use `/agent` to switch from the parent to the child, or back and forth. 5. Observe a terminal completion notification containing old message A at thread-selection time. This was reproduced with multiple child threads. ### Expected behavior Replay, whether caused by resume or by selecting another agent thread, may reconstruct transcript and UI state but must not emit a fresh external completion notification. ### Actual behavior Historical `task_complete` events replayed while selecting a thread cause `Notification::AgentTurnComplete` to be emitted again. ### Source-level diagnosis The current source path passes replay state into task completion handling: - `handle_turn_completed_notification` passes `replay_kind.is_some()` to `on_task_complete(..., from_replay)`. - `on_task_complete` guards several replay-only side effects with `!from_replay`. - The terminal completion notification is still emitted without that guard: ```rust if !follow_up_started && !active_goal_continuing { self.notify(Notification::AgentTurnComplete { ... }); } ``` A likely minimal fix is to include `!from_replay` in this notification guard. A regression test should cover `/agent` selection of a child whose inherited history contains an earlier `task_complete`. ### Local rollout evidence At child creation time, the child rollout begins with inherited historical `task_complete` events from the parent before the child's newer content. Selecting the child replays those events and emits the old notification. The same inherited event shape exists in rollouts created by 0.146.0, suggesting that the unguarded replay side effect predates 0.147.0. ### Related upstream activity - Related issue: #17487 discusses stale final-message state during resume/replay. This report is narrower: an external terminal notification is emitted directly by replay during `/agent` selection. - PR #35693 added background discovery of descendants absent from the current TUI navigation state. That appears to make this latent replay bug much easier to encounter after upgrading to 0.147.0, but the PR is likely an exposure amplifier rather than the root defect. ### Possibly separate symptom Live completion of an unselected background subagent can also produce a terminal notification. That may be a separate notification-policy issue and is not required to reproduce the replay bug described here.", "url": "https://github.com/openai/codex/issues/38192", "createdAt": "2026-08-12T13:52:48Z", "updatedAt": "2026-08-12T13:53:25Z", "timestamp": "2026-08-12T13:53:25Z", "metrics": { "reactions": 0, "comments": 0 }, "labels": [ "bug", "CLI", "subagent" ], "author": "leventov", "state": "open", "assignees": [], "change": "updated" }, { "id": "github:openai/codex:issue:38193", "source": "github", "group": "coding-agent-infrastructure", "project": "openai/codex", "kind": "issue", "title": "Use a separate config overlay for the desktop app", "text": "### What variant of Codex are you using? Codex App (desktop) ### What feature would you like to see? Please give the desktop app its own app-managed config overlay, for example `$CODEX_HOME/config-desktop.toml` (defaulting to `~/.codex/config-desktop.toml`), instead of writing desktop state into the user-managed `$CODEX_HOME/config.toml`. For desktop sessions, configuration should be loaded in this order: 1. `$CODEX_HOME/config.toml` as the user defaults. 2. `$CODEX_HOME/config-desktop.toml` as desktop-specific overrides. When the same key exists in both files, the desktop overlay should win for the desktop app only. Desktop-originated writes—including feature availability, Computer Use hooks, migrations, and settings changed through the app—should target the overlay. The CLI should continue to use the user config without inheriting desktop-only state. This preserves shared defaults across Codex surfaces while establishing a clear ownership boundary: users and their tooling own `config.toml`; the desktop app owns its overlay. ### Additional information The current shared-file behavior makes simply opening the app mutate global configuration and can change CLI behavior or create persistent config churn. Related reports demonstrate several variants of the same ownership problem: - https://github.com/openai/codex/issues/28404 - https://github.com/openai/codex/issues/28184 - https://github.com/openai/codex/issues/24387 - https://github.com/openai/codex/issues/33635 The exact filename is not important; the important properties are separate storage, `$CODEX_HOME` awareness, deterministic merge precedence, and no desktop writes to the user-owned defaults file.", "url": "https://github.com/openai/codex/issues/38193", "createdAt": "2026-08-12T13:57:15Z", "updatedAt": "2026-08-12T13:58:52Z", "timestamp": "2026-08-12T13:58:52Z", "metrics": { "reactions": 1, "comments": 1 }, "labels": [ "enhancement", "app", "config" ], "author": "PaulRBerg", "state": "open", "assignees": [], "change": "updated" }, { "id": "github:openai/codex:issue:38194", "source": "github", "group": "coding-agent-infrastructure", "project": "openai/codex", "kind": "issue", "title": "Hatch Pet v2 look-direction generation progressively shrinks later poses despite fixed-slot geometry and hard source validation", "text": "## Summary While upgrading a custom Codex pet to the v2 16-direction look system, the official coherent-row workflow repeatedly generates later look directions at a much smaller apparent size than the neutral pose. The issue persists even after aligning generation and validation geometry, locking the camera/scale semantics, and using an explicit fixed 8-slot wide layout. The hard source-geometry preflight correctly rejects the bad rows, but the generation step itself still produces progressive shrinkage toward the later directions. This looks like a generation/workflow limitation rather than a registration or validator bug. ## Environment - Platform: Windows 11 - Codex Desktop with custom pet / Hatch Pet workflow - Custom v2 look-direction pipeline (11-row atlas) - Generation row geometry: 2048x768 - 8 equal nominal slots: 256 px each - Returned canvas mapping: proportional W/8 - Source rows must originate from one coherent 8-pose generation job - No per-pose repair, scaling, or translation is permitted ## Neutral geometry used Generation and validation were aligned to the same effective-visible convention (`alpha > 16`). Effective neutral geometry: - visible width: 170 px - visible height: 182 px - planted baseline: 196 - lower-body center: 108.18307567127746 The same values are propagated into: - `pet_request.json` - row-9 prompt - row-10 prompt - all eight construction-guide envelopes - all eight planted baselines / lower-body-center guides ## Generation contract The generation prompt and guide explicitly require: - orthographic character turntable - rotation in place only - locked camera - constant camera distance - constant character scale - constant ground plane - fixed planted-foot baseline - fixed lower-body center - no depth scaling - no perspective size change - no zoom - no forward/backward translation - one pose per fixed nominal slot - no crossing into adjacent slots - no progressive shrinking toward 157.5° / 337.5° The construction guide is 2048x768 with eight identical neutral-derived slot envelopes and chroma-only gutters. ## Latest controlled row-9 result One generation only; no retry. The hard preflight used a single shared prospective scale of `0.610384`. | Direction | Projected height | Baseline | Lower center | Inside nominal slot | |---|---:|---:|---:|---| | 000 | 156 | 196 | 108.062 | No | | 022.5 | 158 | 196 | 108.508 | No | | 045 | 160 | 196 | 107.645 | Yes | | 067.5 | 158 | 196 | 107.859 | Yes | | 090 | 163 | 196 | 108.538 | Yes | | 112.5 | 137 | 196 | 107.466 | No | | 135 | 137 | 196 | 107.954 | No | | 157.5 | 135 | 196 | 108.145 | No | Validator height range: **173–191 px**. All baselines and lower-body-center checks pass, but the generated poses are systematically too small and shrink severely in the later directions. ## Adjacent continuity metrics | Transition | Center shift | Area ratio | Result | |---|---:|---:|---| | 000 → 022.5 | 9.06 px | 1.063x | center fail | | 022.5 → 045 | 18.53 px | 1.175x | center + area + gutter fail | | 045 → 067.5 | 12.04 px | 1.134x | center fail | | 067.5 → 090 | 6.96 px | 1.005x | pass | | 090 → 112.5 | 13.00 px | 1.146x | center fail | | 112.5 → 135 | 0.50 px | 1.001x | pass | | 135 → 157.5 | 3.64 px | 1.018x | pass | Several poses also cross their nominal W/8 slot boundaries. ## Important observation Baseline and lower-body-center consistency are now good. The persistent failure is mainly **apparent scale drift in the generated artwork itself**, especially at 112.5°, 135°, and 157.5°. A global shared registration transform cannot fix this: increasing the smallest later pose enough to reach the minimum would make earlier poses too large. Per-pose normalization would violate the coherent-row/shared-scale constraints. ## Safeguards already added locally The local workflow now hard-blocks bad rows before assembly or installation. It checks: - exactly 8 ordered isolated pose groups - source slot/gutter containment - one shared prospective registration scale - projected height - baseline - lower-body center - adjacent center shift - adjacent apparent-area ratio - projected edge safety A failed row 9 blocks row 10 and installation. The local Hatch Pet regression suite currently passes 50 tests, and validator/assembly behavior was intentionally left unchanged while generation-facing guidance was strengthened. ## Expected behavior A single coherent 8-pose look row should preserve neutral-matched apparent size across all directions while rotating in place, with no progressive shrinking or slot drift. ## Actual behavior The generated row repeatedly becomes smaller toward later angles, even with fixed-slot construction guides and explicit constant-camera/constant-scale constraints. The hard preflight rejects it, so no valid v2 candidate can be produced. ## Questions 1. Is there a known/recommended generation workflow for v2 look rows that reliably preserves constant apparent scale across 8 coherent directions? 2. Is this a known limitation of the current image-generation step used by Hatch Pet / Codex pets? 3. Are there recommended prompt patterns, canvas/aspect settings, or reference-image strategies that have produced stable 16-direction pets? 4. Is there an official v2 Hatch Pet implementation newer than the currently published v1-oriented `openai/skills` version? 5. If coherent source rows are required, is there any spec-compliant deterministic normalization stage intended for this exact scale-drift failure mode? I can provide the preserved source-geometry JSON diagnostics and example generated strips if useful.", "url": "https://github.com/openai/codex/issues/38194", "createdAt": "2026-08-12T14:01:24Z", "updatedAt": "2026-08-12T14:02:14Z", "timestamp": "2026-08-12T14:02:14Z", "metrics": { "reactions": 0, "comments": 0 }, "labels": [ "bug", "windows-os", "app", "pets", "imagen" ], "author": "1972walker-blip", "state": "open", "assignees": [], "change": "updated" }, { "id": "github:openai/codex:issue:38195", "source": "github", "group": "coding-agent-infrastructure", "project": "openai/codex", "kind": "issue", "title": "Voice dictation input is discarded when Codex asks a clarification question", "text": "### What version of the Codex App are you using (From “About Codex” dialog)? Version 26.803.81509 ### What subscription do you have? Business ### What platform is your computer? Microsoft Windows NT 10.0.26200.0 x64 ### What issue are you seeing? When using voice dictation in the Codex Windows desktop app, an ongoing or recently completed voice input can be discarded if Codex displays a clarification question, for example while working in Plan Mode. This is particularly frustrating with longer dictated prompts because the user may already have spoken for several seconds or longer before the clarification dialog appears. The dictated input is then lost and has to be recorded again. ### What steps can reproduce the bug? 1. Open the Codex desktop app on Windows. 2. Start a task in Plan Mode where Codex may ask clarification questions. 3. While Codex is working, start dictating a new message using voice input. 4. Continue speaking while Codex is processing. 5. Codex displays a clarification question. 6. Observe that the current dictated input is discarded or no longer available. ### What is the expected behavior? Voice input that has already been recorded or transcribed should never be silently discarded when Codex displays a clarification question. ### Additional information Ideally, Codex should: - preserve the current dictation/transcription as a draft; - display the clarification question without replacing the user's input; - restore the draft after the clarification has been answered.", "url": "https://github.com/openai/codex/issues/38195", "createdAt": "2026-08-12T14:05:40Z", "updatedAt": "2026-08-12T14:09:10Z", "timestamp": "2026-08-12T14:09:10Z", "metrics": { "reactions": 0, "comments": 2 }, "labels": [ "bug", "windows-os", "app", "plan" ], "author": "wbdb", "state": "open", "assignees": [], "change": "updated" }, { "id": "github:openai/codex:issue:38196", "source": "github", "group": "coding-agent-infrastructure", "project": "openai/codex", "kind": "issue", "title": "Show authenticated ChatGPT workspace name in /status", "text": "### What variant of Codex are you using? CLI ### What feature would you like to see? Display the authenticated ChatGPT workspace name in the interactive `/status` view. Currently, `/status` shows the account email and plan, for example: Account: user@example.com (Enterprise) For users who have access to multiple ChatGPT workspaces, this does not identify which workspace the current Codex session is using. I'd like `/status` to show the authoritative ChatGPT workspace name associated with the current authentication, for example: Account: user@example.com (Enterprise) Workspace: Example Workspace Ideally, this value should come from the authenticated workspace metadata rather than from a locally configured display name. ### Additional information I'm using Codex CLI v0.147.0. I searched existing issues before filing this. Two related issues are: - #10233 proposes a non-interactive/headless status interface. Its proposed schema includes `account.workspace.id` and `account.workspace.name`. - #6360 discusses `/status` account/session identification when multiple logins are involved. This request is narrower than #10233: I'm specifically requesting that the **existing interactive `/status` view** display the authenticated ChatGPT workspace name. The motivation is to make it possible to verify at a glance that Codex is operating under the intended ChatGPT Enterprise/Business workspace. An email address plus `(Enterprise)` does not necessarily distinguish between workspaces available to that account. My current `/status` already displays identity and session information such as Account, Directory, Thread name, Collaboration mode, and Session, so the authenticated workspace seems like a natural field to display alongside Account. If workspace metadata is already available to Codex, it would be preferable to display that authoritative value rather than introduce a user-configurable workspace label.", "url": "https://github.com/openai/codex/issues/38196", "createdAt": "2026-08-12T14:07:10Z", "updatedAt": "2026-08-12T14:07:48Z", "timestamp": "2026-08-12T14:07:48Z", "metrics": { "reactions": 0, "comments": 0 }, "labels": [ "enhancement", "auth", "TUI", "CLI" ], "author": "azat-badretdin", "state": "open", "assignees": [], "change": "updated" }, { "id": "github:openai/codex:issue:38198", "source": "github", "group": "coding-agent-infrastructure", "project": "openai/codex", "kind": "issue", "title": "Codex Desktop: MCP connector is permanently disabled with no re-authenticate affordance after a failed OAuth token refresh", "text": "### What version of the Codex App are you using (From “About Codex” dialog)? Version 26.803.81509 ### What subscription do you have? Enterprise ### What platform is your computer? Darwin 25.6.0 arm64 arm ### What issue are you seeing? When an MCP server's OAuth **token refresh** fails in a way Codex cannot parse, Codex marks that server permanently unusable and offers no way to recover from the UI. The connector's tools silently disappear, no error is surfaced in the app, and the **Authenticate** button does not appear. Restarting Codex Desktop does not help — the same failed refresh is retried on every launch, indefinitely. The stored credential is never invalidated, so Codex keeps attempting a refresh that cannot succeed instead of falling back to a fresh authorization flow. The initial failure, from `~/.codex/logs_2.sqlite`: ``` [DEBUG] rmcp::transport::auth refresh_transaction{server_name= refresh_reason=\"expiry\"}: refresh token present, attempting refresh [WARN] codex_rmcp_client::oauth::refresh_transaction refresh_transaction{server_name= refresh_reason=\"expiry\"}: MCP OAuth provider refresh failed error=OAuth token refresh failed: Failed to parse server response [WARN] codex_rmcp_client::oauth::refresh_transaction MCP OAuth refresh transaction failed server_name= refresh_reason=\"expiry\" ``` On every subsequent launch — across two days and many app restarts — the credential loads fine, but the client is never marked ready: ``` [TRACE] codex_keyring_store mcp.runtime.refresh:new{server_name=}:make_rmcp_client{server_name=}: keyring.load success, service=Codex MCP Credentials, account=| [TRACE] codex_mcp::connection_manager::tool_catalog mcp.runtime.resolve_for_step: omitting MCP server without an exact ready client server_name= ``` Note the asymmetry there: the keyring load **succeeds**, so as far as the app is concerned the connector is authenticated — which appears to be why no Authenticate button is offered. But the client is never constructed, so none of its tools are ever registered, and the connector is silently absent from every conversation. Another OAuth MCP server configured identically on the same machine kept working throughout, so this is not a general connectivity or configuration problem — it is one connector latching into a dead state after a single failed refresh. ### What steps can reproduce the bug? 1. Configure an MCP server over HTTP with `\"auth\": \"oauth\"` and complete the authorization flow successfully. 2. Let the access token reach expiry so Codex attempts a refresh using the stored refresh token. 3. Have the token endpoint return a response Codex cannot parse as an OAuth token response. In my case it returned `HTTP 500`/`502` with `Content-Type: application/json` but an HTML error page as the body: ``` HTTP/2 500 content-type: application/json 502 Bad Gateway ... ``` 4. Observe that the connector's tools vanish, no error appears in the UI, and no Authenticate button is offered. 5. Restart Codex Desktop. The connector stays dead. Any token endpoint that returns a non-JSON body under a JSON content type will reproduce step 3. This is a normal thing for a server to do on an error path — a reverse proxy or load balancer sitting in front of an OAuth server will often return its own HTML error page while passing through the upstream's content-type header. It doesn't require the token endpoint to be misconfigured, only to be briefly unhealthy at the moment a refresh happens. Since access tokens expire on the order of an hour, every user of that server gets a fresh chance to hit it. ### What is the expected behavior? A failed token refresh should be recoverable without manual keychain surgery. Any of the following would fix it: 1. **Surface the Authenticate affordance.** If a refresh fails and the client cannot be constructed, treat the connector as needing authentication and show the Authenticate button, rather than presenting it as connected-but-toolless. 2. **Surface the error.** The failure is currently invisible in the UI — I only found it by querying the log database. At minimum the connector should show an error state. 3. **Don't treat an unparseable refresh response as terminal.** An unparseable body carries no information about whether the refresh token is still valid, so falling back to a full authorization flow is strictly safer than latching dead forever. 4. **Invalidate the stored credential when refresh fails unrecoverably**, so the next launch starts a clean flow instead of replaying a dead refresh. Being defensive here matters because Codex can't control what a third-party or self-hosted token endpoint returns on its error paths. #####WORKAROUND##### Deleting the stored credential from the macOS Keychain forces Codex to start a fresh authorization flow. The Authenticate button reappears immediately afterward and the connector works again. Codex stores MCP credentials as generic passwords under the service `Codex MCP Credentials`, with the account name in the form `|`. The hash is not derivable from the server URL, so it has to be looked up: ```bash acct=$(security dump-keychain | grep -A4 'Codex MCP Credentials' \\ | grep '\"acct\"' | sed -E 's/.*=\"(.*)\"/\\1/' | grep '^|') security delete-generic-password -s \"Codex MCP Credentials\" -a \"$acct\" ``` Then restart Codex Desktop. This is the only recovery I found — no combination of restarting, toggling the server off and on, or starting new conversations had any effect. ### Additional information _No response_", "url": "https://github.com/openai/codex/issues/38198", "createdAt": "2026-08-12T14:15:43Z", "updatedAt": "2026-08-12T18:44:28Z", "timestamp": "2026-08-12T18:44:28Z", "metrics": { "reactions": 0, "comments": 0 }, "labels": [ "bug", "auth", "mcp", "app" ], "author": "david-montry-zocdoc", "state": "open", "assignees": [] }, { "id": "github:openai/codex:issue:38199", "source": "github", "group": "coding-agent-infrastructure", "project": "openai/codex", "kind": "issue", "title": "GPT-5.3-Codex-Spark quota available on Pro account but model missing from Codex App selector", "text": "### What version of the Codex App are you using (From “About Codex” dialog)? 26.803.61601 ### What subscription do you have? ChatGPT Pro ### What platform is your computer? Darwin 25.5.0 arm64 arm ### What issue are you seeing? Issue Description I am a ChatGPT Pro subscriber and my account currently has a separate GPT-5.3-Codex-Spark weekly usage quota with 90% remaining. However, GPT-5.3-Codex-Spark does not appear in the model selector in the Codex desktop app. The models currently available in my Codex App selector are: * GPT-5.6 Sol * GPT-5.6 Terra * GPT-5.6 Luna * GPT-5.5 * GPT-5.2 GPT-5.3-Codex-Spark is completely missing. At the same time, the Codex usage page clearly shows a dedicated “GPT-5.3-Codex-Spark usage limit” with 90% remaining and the same weekly reset date. This appears to be an inconsistency between my account entitlement/quota and the models exposed by the Codex App. Could you please confirm whether: 1. GPT-5.3-Codex-Spark has intentionally been removed from the Codex App model selector; 2. this is part of a staged rollout/model availability change; or 3. this is an account entitlement/model-selector synchronization bug? \"Image\" \"Image\" I have attached screenshots showing both the missing model in the Codex App selector and the available GPT-5.3-Codex-Spark quota. ### What steps can reproduce the bug? Feedback ID: 019ff646-cf5f-7cd3-8c1e-9a571c8aa8ca ### What is the expected behavior? GPT-5.3-Codex-Spark should appear in the Codex App model selector for my ChatGPT Pro account while my account has an active dedicated GPT-5.3-Codex-Spark usage quota. If Spark has intentionally been removed or temporarily disabled in the Codex App, the usage/limits page should clearly reflect that change instead of continuing to show an active separate Spark quota. ### Additional information _No response_", "url": "https://github.com/openai/codex/issues/38199", "createdAt": "2026-08-12T14:17:04Z", "updatedAt": "2026-08-12T14:18:53Z", "timestamp": "2026-08-12T14:18:53Z", "metrics": { "reactions": 0, "comments": 1 }, "labels": [ "bug", "rate-limits", "app" ], "author": "dengdingchang", "state": "open", "assignees": [], "change": "updated" }, { "id": "github:openai/codex:issue:38200", "source": "github", "group": "coding-agent-infrastructure", "project": "openai/codex", "kind": "issue", "title": "ChatGPT desktop conversations not syncing to web or iOS", "text": "Several conversations visible in the ChatGPT Mac desktop app are absent from chatgpt.com and the ChatGPT iPhone app under the same OpenAI account. Most important example “MFL Master / continuation” is visible and pinned in the Mac desktop app but is completely absent from ChatGPT web and the iPhone app. Searching for the exact title on the web does not locate it. The problem is broader than one conversation. “MFL Verified Master Audit” appears in the Mac app’s Recents list but does not appear in the corresponding visible web Chats list. Side-by-side screenshots show that the desktop Recents inventory and web Chats inventory do not match. I never intentionally created these conversations as local-only Work chats. The interface did not clearly warn me that these conversations would remain only on one computer or give me an intentional choice to prevent cloud synchronization. Steps to reproduce 1. Sign in to the same OpenAI account in the ChatGPT Mac app, chatgpt.com and the ChatGPT iPhone app. 2. In the Mac app, view Pinned and Recents. 3. Confirm that “MFL Master / continuation” appears under Pinned and “MFL Verified Master Audit” appears under Recents. 4. Open ChatGPT web and the iPhone app under the same account. 5. Search and browse the available conversations. 6. “MFL Master / continuation” is absent from both web and iPhone, and the overall conversation inventories do not match. Expected behavior Cloud Chat and Work conversations should synchronize across desktop, web and mobile. If a conversation is being created as local-only, that status should be explicit before work begins. Please determine why these conversations are not synchronizing, restore cloud access without losing their contents, and clarify how users can identify and prevent local-only conversations. Business impact These are active business records. If I am away from my computer and have only my phone, I cannot access or continue essential work. Reconstructing or manually duplicating long conversations is not a practical workaround. System information ChatGPT subscription: Pro Mac desktop app: 26.803.61601 Initially reported under: 26.803.41515 Computer: macOS, Apple silicon/arm64 Other affected surfaces: chatgpt.com in Safari and ChatGPT iPhone app Model visible during documentation: GPT-5.6 Sol Light, although the synchronization failure does not appear model-specific Timeline First formally reported August 10, 2026. The problem remains unresolved on August 12, 2026 and persisted after the desktop application updated. Existing diagnostic Feedback ID no-active-thread-019fedb4-03eb-7f73-952a-e3e955d89a34 \"Image\" \"Image\"", "url": "https://github.com/openai/codex/issues/38200", "createdAt": "2026-08-12T14:21:31Z", "updatedAt": "2026-08-12T14:24:07Z", "timestamp": "2026-08-12T14:24:07Z", "metrics": { "reactions": 0, "comments": 1 }, "labels": [ "bug", "app", "session" ], "author": "LittleChimpanzeeMonkey", "state": "open", "assignees": [], "change": "updated" }, { "id": "github:openai/codex:issue:38201", "source": "github", "group": "coding-agent-infrastructure", "project": "openai/codex", "kind": "issue", "title": "Allow users to configure how many conversations appear in Recents", "text": "### What variant of Codex are you using? Codex Desktop / App ### What feature would you like to see? Please let users choose how many conversations are shown in the **Recents** section of the sidebar. A useful setting could offer values such as **5, 10, 20, 50, or All**, with a **Show more** action for anything beyond the chosen initial count. I use projectless conversations for recurring tasks such as daily briefs. These create many short-lived threads, so showing 50 recent conversations makes the Recents section very long and pushes my Projects too far down the sidebar. Moving Recents below Projects only reverses the problem: Recents then becomes too far down to reach conveniently. The visible Recents count should be a presentation preference, separate from conversation retention and loading. Choosing a small number must not hide conversations from search, remove history, or limit the full paginated history available inside each project. ### Expected behavior - Users can configure the number of conversations initially visible under Recents. - A small selection such as 5 or 10 keeps Projects easy to reach. - Older conversations remain available through search and a Show more / full-history view. - Project conversation history continues to load independently of the global Recents display count. ### Related issue This is related to #25761, but it addresses a different need. That issue asks for complete access to older project conversations beyond the global recent-50 window. This request asks for control over how many recent conversations are visibly expanded in the sidebar, without reducing access to any saved history.", "url": "https://github.com/openai/codex/issues/38201", "createdAt": "2026-08-12T14:23:21Z", "updatedAt": "2026-08-12T14:24:00Z", "timestamp": "2026-08-12T14:24:00Z", "metrics": { "reactions": 0, "comments": 0 }, "labels": [ "enhancement", "app", "session" ], "author": "Guntheruk", "state": "open", "assignees": [], "change": "updated" }, { "id": "github:openai/codex:issue:38202", "source": "github", "group": "coding-agent-infrastructure", "project": "openai/codex", "kind": "issue", "title": "Windows Codex Desktop repeatedly shows main-process error \"Error: write EOF\" after update", "text": "### What version of Codex is running? - Codex Desktop for Windows (Microsoft Store) - Package version: `26.803.10989.0` - Architecture: x64 ### What is happening? Since updating the Codex Windows desktop app, a modal error appears frequently at unrelated points during normal use. The app had not shown this error before the update. Exact dialog text: ```text A JavaScript error occurred in the main process Uncaught Exception: Error: write EOF at WriteWrap.onWriteComplete [as oncomplete] (node:internal/stream_base_commons:87:19) ``` The error is not tied to one project action: it can appear at different times while using the app. ### Troubleshooting already tried - Used Windows Settings > Apps > Codex > Advanced options > Repair (`Восстановить`) - Fully restarted the app / Windows Repair did not resolve the issue. A full app reset was deliberately not attempted because preserving local Codex history and settings is important. ### Expected behavior Codex should handle a closed internal stream/child process without surfacing a recurring uncaught main-process exception to the user. ### Impact The error interrupts work repeatedly and began immediately after the update. It does not appear to be caused by a particular repository or action.", "url": "https://github.com/openai/codex/issues/38202", "createdAt": "2026-08-12T14:42:36Z", "updatedAt": "2026-08-12T14:43:51Z", "timestamp": "2026-08-12T14:43:51Z", "metrics": { "reactions": 0, "comments": 1 }, "labels": [ "bug", "windows-os", "app" ], "author": "Araaniart", "state": "open", "assignees": [], "change": "updated" }, { "id": "github:openai/codex:issue:38203", "source": "github", "group": "coding-agent-infrastructure", "project": "openai/codex", "kind": "issue", "title": "[Windows Desktop 26.803.10989.0] codex-code-mode-host 0xc0000409 crash leaves concurrent exec calls stuck until restart", "text": "### What version of the Codex App are you using (From “About Codex” dialog)? 26.803.10989.0 ### What subscription do you have? ChatGPT Pro ### What platform is your computer? Microsoft Windows NT 10.0.26200.0 x64 ### What issue are you seeing? On Codex Desktop for Windows, a crash of `codex-code-mode-host.exe` left six outstanding code-mode `exec` calls in unrelated tasks pending indefinitely. The affected tasks continued to appear “in progress” without an error or timeout until the whole Codex app was restarted. I first observed this with six unrelated tasks using tools concurrently. All six stopped making progress at tool calls. Restarting Codex recovered the tasks. The same host crash fingerprint recurred later during the diagnostic session while a small read-only `exec` call was running. That call returned: ```text code-mode host closed its stdout ``` Windows recorded the same native crash fingerprint for both occurrences on the current app build: ```text Faulting application: codex-code-mode-host.exe Faulting module: ntdll.dll Exception code: 0xc0000409 Fault offset: 0x000000000013a375 WER report bucket: 0f934d2d574646e44c274226f283d7dc ``` `0xc0000409` is a Windows fail-fast exception. It does not by itself establish a stack-buffer-overflow root cause; Microsoft notes that applications also use this fail-fast code for other unrecoverable conditions: https://learn.microsoft.com/en-us/shows/inside/c0000409 Evidence connecting the unresolved task calls to the host exit: - The six affected session transcripts each end at an outbound `custom_tool_call` named `exec`, with no matching `custom_tool_call_output` before the app restart. - The nested operations span both `shell_command` and `apply_patch` in unrelated tasks, so this was not isolated to one command, workspace, or tool implementation. - The first host crash was recorded at `2026-08-12 22:17:29.357 UTC+08:00` (`14:17:29.357Z`). The desktop app server answered requests at `22:46:56` while the six affected calls were still unresolved, shortly before the user restarted the app. - During diagnosis, another host crash recurred at `2026-08-12 22:57:50 UTC+08:00` (`14:57:50Z`) while a small read-only `exec` was running. The outer call returned `code-mode host closed its stdout`, and Windows simultaneously recorded the identical application, module, exception code, fault offset, and WER bucket. The host process then restarted automatically about seven seconds later. - No Windows System resource-exhaustion event was recorded between `22:00` and `23:00` local time. The crash is therefore directly observed and recurrent on this machine. The exact native trigger is still unknown. I cannot attribute it to any one command: one call that began 227 ms before the first recorded crash still returned after the crash, while six unrelated outstanding calls remained unresolved. ### What steps can reproduce the bug? The native crash is intermittent; I do not yet have a deterministic minimal trigger. The observed sequence is: 1. Open several unrelated Codex Desktop tasks and let them run tool calls concurrently (six tasks were active in the original incident). 2. Continue normal work involving `shell_command` and `apply_patch` through code-mode `exec`. 3. When `codex-code-mode-host.exe` terminates, observe that the affected calls remain “running” indefinitely rather than failing. 4. Restart the entire Codex app. The orphaned tasks become usable again. 5. In the later diagnostic occurrence, the same host process terminated while a small read-only `exec` was running. The call surfaced `code-mode host closed its stdout`, and a replacement host started automatically about seven seconds later. In the original incident, however, the six unresolved calls did not leave the running state before the full app restart. I found two minidumps for the current-build crashes in the Windows user CrashDumps directory. Session IDs, full transcripts, local paths, prompts, and dumps are intentionally omitted from this public report because they may contain private project data. I can provide redacted event records or arrange a private dump transfer if maintainers provide a secure channel. ### What is the expected behavior? When the code-mode host exits, the app should promptly reject all still-unresolved requests that can no longer receive a response from it and move the corresponding tasks out of the running state with an actionable error. It should then restart the host without requiring a full app restart. For potentially side-effectful operations, the app should not silently replay an orphaned request. If completion cannot be determined, it should report that execution state is unknown so the user can reconcile filesystem or external effects before retrying. ### Additional information - Installed package: `OpenAI.Codex_26.803.10989.0_x64__2p2nqsd0c76g0` - Windows Application log contains nine `codex-code-mode-host.exe` crashes in the last 30 days. Four share the exact `ntdll.dll` / `0xc0000409` / `0x13a375` signature, on 2026-08-06, 2026-08-08, and twice on 2026-08-12. This exact family spans at least app builds `26.730.8199.0`, `26.803.5235.0`, and `26.803.10989.0`. - Other historical host crashes on this machine used `0xc0000005` or `0xc0000374`; I am not claiming that those have the same root cause without symbols or dump analysis. Related reports reviewed before filing: - #38190 reports an `apply_patch` hang on the same app build, but shell I/O remains healthy there and no matching WER host crash is reported. - #37694 reports a code-mode host crash after extreme image-history memory growth, with a different `0x80000003` signature. - #36096 records `codex.exe` as the faulting application and module. - #37164 reports `codex.exe` fast-fails in earlier WER records and attributes newer Crashpad dumps to a likely Electron utility process. Neither report contains this `codex-code-mode-host.exe` fingerprint plus unresolved concurrent calls. I did not find an existing report with this combination of a repeatable host crash fingerprint and failure to reject all outstanding requests after the host exits.", "url": "https://github.com/openai/codex/issues/38203", "createdAt": "2026-08-12T15:15:55Z", "updatedAt": "2026-08-12T15:16:37Z", "timestamp": "2026-08-12T15:16:37Z", "metrics": { "reactions": 0, "comments": 0 }, "labels": [ "bug", "windows-os", "tool-calls", "app" ], "author": "Utopia-V", "state": "open", "assignees": [], "change": "updated" }, { "id": "github:openai/codex:issue:38206", "source": "github", "group": "coding-agent-infrastructure", "project": "openai/codex", "kind": "issue", "title": "Codex Desktop shows “Conversation not found” during new-session startup with SessionStart hooks", "text": "### What version of the Codex App are you using (From “About Codex” dialog)? Codex App 26.803.61601 (bundled Codex CLI/app-server 0.147.0-alpha.6.5) ### What subscription do you have? Not collected / not available in this session context. ### What platform is your computer? `Darwin 25.6.0 arm64 arm` ### What issue are you seeing? Every time I start a new Codex Desktop session in a project with Engine installed, the app shows a red toast: > Conversation not found This is a transient UI error: the new session is actually created, the Engine startup briefing arrives, and the conversation continues normally. It is not tied to running an Engine upgrade; it also happens on ordinary new-session startup. The affected project has six `SessionStart` commands in `.codex/hooks.json`. The user observes the toast deterministically whenever starting a session with this setup. ### What steps can reproduce the bug? 1. Open a trusted local project in Codex Desktop that has a nontrivial `.codex/hooks.json` with multiple `SessionStart` hooks (the reproducing setup has six). 2. Start a new task/session. 3. As the session initializes, observe a red **“Conversation not found”** toast. 4. Wait briefly. 5. Observe that the same session remains usable and its startup context appears normally. The startup sequence captured in the reproducing session was: - 18:11:43 — thread creation and user submission logged. - 18:11:48 — thread resume response logged. - 18:11:49 — startup briefing/context from the `SessionStart` hooks arrived. - 18:11:50.951 and 18:11:50.977 — renderer/Sentry breadcrumbs logged: `Matched leaf route at location \"/\" does not have an element or Component. This means it will render an with a null value by default resulting in an \"empty\" page.` - The red toast appeared during this startup window. - No corresponding warning/error or “Conversation not found” entry appeared in the backend/app-server logs, and the session continued successfully. The hooks themselves appear healthy: - The Engine hook test suite passes: **76 tests, OK**. - Manually running the boot hook exits 0 and emits valid `SessionStart` JSON with `hookSpecificOutput.additionalContext`. - The project’s two Engine MCP health checks pass. ### What is the expected behavior? Starting a valid new session should not show a missing-conversation error. Codex Desktop should wait until the renderer’s conversation state/routing is ready, or suppress a transient lookup failure when the session is known to be initializing. ### Additional information This looks like a renderer/UI timing race exposed by startup-hook latency, but that is an inference, not a confirmed root cause. The exact frontend request that triggers the toast was not present in the collected backend logs. Possibly related: #16817 describes a renderer race involving conversation state, although that issue concerns existing threads after restart rather than this transient new-session startup behavior. A screenshot of the toast is available if needed.", "url": "https://github.com/openai/codex/issues/38206", "createdAt": "2026-08-12T15:36:58Z", "updatedAt": "2026-08-12T15:37:34Z", "timestamp": "2026-08-12T15:37:34Z", "metrics": { "reactions": 0, "comments": 0 }, "labels": [ "bug", "app", "hooks" ], "author": "StarshipSuperjam", "state": "open", "assignees": [], "change": "updated" }, { "id": "github:openai/codex:issue:38208", "source": "github", "group": "coding-agent-infrastructure", "project": "openai/codex", "kind": "issue", "title": "macOS Computer Use permission setup is too complex and should have guided onboarding", "text": "### What variant of Codex are you using? Codex / ChatGPT desktop app on macOS. ### What feature would you like to see? The current setup process for granting the permissions required by **Computer Use** on macOS feels unnecessarily complicated and cumbersome. Enabling Computer Use may require users to understand and manually navigate multiple macOS privacy/security permission areas. For a user who simply wants to enable Computer Use safely, the flow is not very intuitive and it is easy to be unsure which permissions are still missing or whether the setup is complete. I would like to see a first-class guided permission setup flow in the Codex desktop app. Suggested improvements: - Show all required Computer Use permissions in one place. - Clearly indicate which permissions are already granted and which are still missing. - Provide a direct action to open the relevant macOS Privacy & Security page for each permission. - Explain briefly why each permission is required before asking the user to grant it. - Detect permission changes automatically when the user returns to Codex. - Show a clear final state such as **Computer Use is ready** once everything is configured. - Provide a simple repair/recheck flow if Computer Use later stops working because a permission was revoked or changed. The goal is not to weaken macOS security or reduce user consent. The goal is to make the existing permission process easier to understand and complete safely. ### Why this matters Computer Use is a powerful feature, but the initial authorization experience creates unnecessary friction. A guided onboarding/checklist would make the feature much more approachable, especially for users who are not familiar with macOS Accessibility, Screen Recording, and related privacy controls. I am happy to provide screenshots, describe the current permission flow in more detail, or test an improved onboarding experience if useful.", "url": "https://github.com/openai/codex/issues/38208", "createdAt": "2026-08-12T15:57:06Z", "updatedAt": "2026-08-12T15:57:45Z", "timestamp": "2026-08-12T15:57:45Z", "metrics": { "reactions": 0, "comments": 0 }, "labels": [ "enhancement", "app", "computer-use" ], "author": "youyun863", "state": "open", "assignees": [], "change": "updated" }, { "id": "github:openai/codex:issue:38209", "source": "github", "group": "coding-agent-infrastructure", "project": "openai/codex", "kind": "issue", "title": "Codex Desktop on Windows does not support multi-monitor different DPI setup", "text": "### What version of the Codex App are you using (From “About Codex” dialog)? 26.803.81509 ### What subscription do you have? Pro ### What platform is your computer? Ubuntu 24 ### What issue are you seeing? The Codex Linux app does not appear to fully support Wayland setups with multiple monitors using different DPI/scaling settings. When moving the Codex window between monitors with different scaling factors, the UI may render at an incorrect scale or behave inconsistently. **Expected behavior:** The app should correctly detect and adapt to the scaling factor of each monitor when the window is moved between displays. **Actual behavior:** Scaling/DPI handling is inconsistent across monitors. ### What steps can reproduce the bug? 1. Install Codex App on Ubuntu 2. Switch from any-dpi to a higher or lower dpi screen ### What is the expected behavior? Like chrome/firefox/vscode apps should scale UI. ### Additional information _No response_", "url": "https://github.com/openai/codex/issues/38209", "createdAt": "2026-08-12T16:13:06Z", "updatedAt": "2026-08-12T16:14:29Z", "timestamp": "2026-08-12T16:14:29Z", "metrics": { "reactions": 0, "comments": 1 }, "labels": [ "bug", "app" ], "author": "katsar0v", "state": "open", "assignees": [], "change": "updated" }, { "id": "github:openai/codex:issue:38210", "source": "github", "group": "coding-agent-infrastructure", "project": "openai/codex", "kind": "issue", "title": "TUI: quick-cancelled optimistic prompt remains selectable but has no persisted UserMessage", "text": "### What version of Codex CLI is running? codex-cli 0.147.0 ### What subscription do you have? ChatGPT subscription (exact tier omitted; this appears to be a local TUI persistence race) ### Which model were you using? gpt-5.6-sol ### What platform is your computer? Darwin 25.6.0 arm64 arm ### What terminal emulator and version are you using (if applicable)? Ghostty 1.3.1 ### Codex doctor report Not included because it contains unrelated local paths. The relevant persisted state is summarized below. ### What issue are you seeing? If a newly submitted prompt is cancelled very quickly, it can remain visible in the TUI transcript and in prompt recall even though it never becomes a persisted `UserMessage`. Esc-Esc then offers that optimistic-only prompt as a backtrack target, but selecting it fails with: ```text Failed to branch before the selected prompt: the selected prompt was not found in the persisted thread ``` This is narrower than #37421 and does not appear to be covered by #37622. That fix reconstructs turns whose `UserMessage` already exists in buffered server notifications. In this reproduction, no user-message item exists in the rollout, replayable thread items, or thread database. Observed state after the failure: - Cross-session prompt history contains the submitted text. - The TUI transcript contains a selectable user-history cell for it. - The rollout contains `task_started` followed by `turn_aborted`, with no user `response_item` for the submitted prompt. - The corresponding `thread_turns` row is `interrupted`, with an empty `first_user_item_id`. - There is no matching `userMessage` in `thread_items`. The local timing was: - Prompt submission received. - Interrupt received approximately 743 ms later. - The task did not complete gracefully within the subsequent 100 ms cancellation window and was forcibly aborted. The source appears to permit this split state: - `input_submission.rs` renders the prompt optimistically before submitting the operation and separately records prompt recall: https://github.com/openai/codex/blob/rust-v0.147.0/codex-rs/tui/src/chatwidget/input_submission.rs#L359-L405 - `app_backtrack.rs` selects from visible `UserHistoryCell` entries, then resolves the selection against persisted `ThreadItem::UserMessage` entries and emits the error above if none matches: https://github.com/openai/codex/blob/rust-v0.147.0/codex-rs/tui/src/app_backtrack.rs#L463-L573 Five `UserPromptSubmit` hooks were configured in the reproducing environment. The logs do not identify the exact pre-persistence stage active at cancellation, so this does not establish that any specific hook caused the failure; hook processing may simply widen the timing window. ### What steps can reproduce the bug? 1. Start a new interactive Codex CLI session. 2. Submit a short prompt such as `Hello`. 3. Immediately press Esc once, before the turn has durably recorded its user-message item. 4. With the composer empty, press Esc twice. 5. Select the just-cancelled prompt and press Enter. 6. Observe that Codex restores the prompt but reports that it was not found in the persisted thread. This is timing-sensitive interactively. A deterministic test could delay pre-persistence startup or a `UserPromptSubmit` hook, cancel before `record_user_prompt_and_emit_turn_item`, and then exercise Esc-Esc against the optimistic transcript cell. ### What is the expected behavior? The backtrack selector should never offer a prompt that cannot serve as a branch anchor. After quick cancellation, Codex should do one of the following: 1. Persist the submitted user message before completing cancellation, allowing normal branching; or 2. Mark/filter the optimistic-only transcript cell so Esc-Esc cannot select it; or 3. Gracefully restore it for editing without attempting an impossible branch and without displaying an internal consistency error. ### Additional information #37622 fixes the related paginated-thread case where live turns exist in the replay buffer but not yet in the snapshot. Its added test supplies an `ItemCompleted(UserMessage)` notification. This reproduction has no such item to merge, so the new reconstruction path appears unable to resolve it. No thread or session identifier is included because this is a public issue; sanitized additional diagnostics can be provided if needed.", "url": "https://github.com/openai/codex/issues/38210", "createdAt": "2026-08-12T16:16:56Z", "updatedAt": "2026-08-12T16:17:38Z", "timestamp": "2026-08-12T16:17:38Z", "metrics": { "reactions": 0, "comments": 0 }, "labels": [ "bug", "TUI", "CLI", "session" ], "author": "astradevkin", "state": "open", "assignees": [], "change": "updated" }, { "id": "github:openai/codex:issue:38211", "source": "github", "group": "coding-agent-infrastructure", "project": "openai/codex", "kind": "issue", "title": "[Windows Desktop] Local PDF file citation link repeatedly disappears from assistant messages", "text": "### What version of the Codex App are you using? Unknown (the installed AppX package version was not available through the current session diagnostics). ### What platform is your computer? Windows desktop (x64). ### What issue are you seeing? A local PDF generated by Codex is delivered using the supported plain file-citation syntax: ``` :codex-file-citation{path=\"C:\\\\Users\\\\\\\\Documents\\\\Codex\\\\\\\\output\\\\pdf\\\\report.pdf\" purpose=\"output\"} ``` The file link initially appears in the assistant response, but later disappears from the rendered conversation. The user has repeatedly had to ask for the link again. Re-emitting the same citation restores it temporarily, but it disappears again. The underlying PDF still exists at the referenced local path. This therefore appears to be a desktop message-rendering or file-citation persistence issue rather than file deletion. This has reproduced multiple times in the same long-running thread with locally generated PDFs. ### What steps can reproduce the bug? 1. Use Codex Desktop on Windows with a local workspace. 2. Ask Codex to generate a PDF under the workspace, for example `output/pdf/report.pdf`. 3. Have the assistant return the PDF using a plain `:codex-file-citation{... purpose=\"output\"}` directive. 4. Confirm that the link appears in the rendered assistant message. 5. Continue the conversation or revisit/refresh the thread. 6. Observe that the file link is no longer visible. 7. Ask Codex to return the link again. 8. Observe that the re-emitted link appears temporarily and can disappear again. ### What is the expected behavior? A rendered local file citation should remain visible and clickable for as long as the referenced file exists and the conversation message remains available. ### Additional information - The issue affects PDF deliverables and disrupts a repeated document-generation workflow. - Re-emitting the same absolute path does not provide a lasting workaround. - The report intentionally omits the Windows username, candidate/customer names, thread identifiers, and full local paths. - Date observed: 2026-08-12.", "url": "https://github.com/openai/codex/issues/38211", "createdAt": "2026-08-12T16:19:23Z", "updatedAt": "2026-08-12T16:20:45Z", "timestamp": "2026-08-12T16:20:45Z", "metrics": { "reactions": 0, "comments": 1 }, "labels": [ "bug", "windows-os", "app" ], "author": "juliuslorr-bot", "state": "open", "assignees": [] }, { "id": "github:openai/codex:issue:38212", "source": "github", "group": "coding-agent-infrastructure", "project": "openai/codex", "kind": "issue", "title": "stream disconnected before completion: error sending request for url (https://chatgpt.com/backend-api/codex/responses)", "text": "/feedback stream disconnected before completion: error sending request for url (https://chatgpt.com/backend-api/codex/responses) Been seeing this message from my Codex APP Desktop Mac. over and over again \"Image\"", "url": "https://github.com/openai/codex/issues/38212", "createdAt": "2026-08-12T16:29:27Z", "updatedAt": "2026-08-12T16:31:04Z", "timestamp": "2026-08-12T16:31:04Z", "metrics": { "reactions": 0, "comments": 1 }, "labels": [ "bug", "app", "connectivity" ], "author": "sathvik077", "state": "open", "assignees": [] }, { "id": "github:openai/codex:issue:38213", "source": "github", "group": "coding-agent-infrastructure", "project": "openai/codex", "kind": "issue", "title": "App-server does not dispatch Stop hook after turn/completed", "text": "## Summary When a normal app-server turn reaches `turn/completed`, the configured `Stop` hook is not dispatched. ## Environment - Codex CLI: `0.147.0-alpha.6.5` - OS: macOS - Transport: app-server over stdio - Isolated temporary `CODEX_HOME` and repository fixture - No global hook installation or user configuration changes ## Reproduction 1. Configure trusted lifecycle hooks for `SessionStart`, `UserPromptSubmit`, `Stop`, `PostCompact`, and `SessionEnd`. 2. Start app-server. 3. Start a temporary persisted thread and a no-tools turn. 4. Wait for the server to emit `turn/completed`. 5. Observe hook lifecycle notifications for up to 10 seconds after completion. ## Expected behavior After `turn/completed`, app-server dispatches the `Stop` hook and emits the corresponding hook lifecycle notifications. ## Actual behavior - `SessionStart` and `UserPromptSubmit` are dispatched. - The turn reaches `turn/completed`. - No `hook/started` notification for `Stop` appears within 10 seconds. - When app-server is then shut down, `SessionEnd` is dispatched. This reproduces consistently in an isolated canary without modifying real user configuration. ## Related issue #22858 discusses interrupted turns. This report concerns a normally completed turn.", "url": "https://github.com/openai/codex/issues/38213", "createdAt": "2026-08-12T16:32:00Z", "updatedAt": "2026-08-12T16:32:50Z", "timestamp": "2026-08-12T16:32:50Z", "metrics": { "reactions": 0, "comments": 0 }, "labels": [ "bug", "CLI", "hooks", "app-server" ], "author": "Weicheng0917-creator", "state": "open", "assignees": [] }, { "id": "github:openai/codex:issue:38215", "source": "github", "group": "coding-agent-infrastructure", "project": "openai/codex", "kind": "issue", "title": "Codex CLI cannot tag / explicitly invoke configured subagents like the Codex app", "text": "### What version of Codex CLI is running? codex-cli 0.147.0 ### What subscription do you have? Plus ### Which model were you using? gpt-5.6-sol ### What platform is your computer? Win 11 Pro x64 ### What terminal emulator and version are you using (if applicable)? PowerShell ### Codex doctor report ```json { \"schemaVersion\": 1, \"generatedAt\": \"1786552514s since unix epoch\", \"overallStatus\": \"warning\", \"codexVersion\": \"0.147.0\", \"checks\": { \"app_server.status\": { \"id\": \"app_server.status\", \"category\": \"app-server\", \"status\": \"ok\", \"summary\": \"background server is not running\", \"details\": { \"control socket\": \"\", \"daemon state dir\": \"\", \"mode\": \"ephemeral\", \"pid file\": \" (missing)\", \"settings\": \" (missing)\", \"status\": \"not running\", \"update-loop pid file\": \" (missing)\" }, \"remediation\": null, \"durationMs\": 0 }, \"auth.credentials\": { \"id\": \"auth.credentials\", \"category\": \"auth\", \"status\": \"ok\", \"summary\": \"auth is configured\", \"details\": { \"auth file\": \"\", \"auth storage mode\": \"File\", \"stored API key\": \"false\", \"stored ChatGPT tokens\": \"true\", \"stored agent identity\": \"false\", \"stored auth mode\": \"chatgpt\" }, \"remediation\": null, \"durationMs\": 0 }, \"config.load\": { \"id\": \"config.load\", \"category\": \"config\", \"status\": \"ok\", \"summary\": \"config loaded\", \"details\": { \"CODEX_HOME\": \"\", \"config.toml\": \"\", \"config.toml parse\": \"ok\", \"cwd\": \"\", \"enabled feature flags\": \"\", \"feature flag overrides\": \"memories=true, prevent_idle_sleep=true\", \"feature flags enabled\": \"41\", \"log dir\": \"\", \"mcp servers\": \"0\", \"model\": \"gpt-5.6-sol\", \"model provider\": \"openai\", \"sqlite home\": \"\" }, \"remediation\": null, \"durationMs\": 3 }, \"git.environment\": { \"id\": \"git.environment\", \"category\": \"git\", \"status\": \"ok\", \"summary\": \"git version 2.54.0.windows.1\", \"details\": { \"PATH git #1\": \"C:\\\\Program Files\\\\Git\\\\cmd\\\\git.exe\", \"PATH git entries\": \"1\", \"git build options\": \"git version 2.54.0.windows.1; cpu: x86_64; built from commit: 2b8a3ab140826ac423c2845ef81d4c6ac4f7bf3c; sizeof-long: 4; sizeof-size_t: 8; shell-path: D:/git-sdk-64-build-installers/usr/bin/sh; rust: disabled; feature: fsmonitor--daemon; gettext: enabled; libcurl: 8.19.0; OpenSSL: OpenSSL 3.5.6 7 Apr 2026; zlib: 1.3.2; SHA-1: SHA1_DC; SHA-256: SHA256_BLK; default-ref-format: files; default-hash: sha1\", \"git exec path\": \"C:/Program Files/Git/mingw64/libexec/git-core\", \"git version\": \"git version 2.54.0.windows.1\", \"repo detected\": \"false\", \"selected git\": \"C:\\\\Program Files\\\\Git\\\\cmd\\\\git.exe\" }, \"remediation\": null, \"durationMs\": 171 }, \"installation\": { \"id\": \"installation\", \"category\": \"install\", \"status\": \"ok\", \"summary\": \"installation looks consistent\", \"details\": { \"PATH codex #1\": \"\", \"PATH codex #2\": \"\", \"PATH codex #3\": \"\", \"PATH codex #4\": \"\", \"PATH codex #5\": \"\", \"PATH codex entries\": \"5\", \"current executable\": \"\", \"install context\": \"npm ()\", \"managed by bun\": \"false\", \"managed by npm\": \"true\", \"managed by pnpm\": \"false\", \"managed package root\": \"\", \"npm update target\": \"\" }, \"remediation\": null, \"durationMs\": 512 }, \"mcp.config\": { \"id\": \"mcp.config\", \"category\": \"mcp\", \"status\": \"ok\", \"summary\": \"no MCP servers configured\", \"details\": {}, \"remediation\": null, \"durationMs\": 0 }, \"network.env\": { \"id\": \"network.env\", \"category\": \"network\", \"status\": \"ok\", \"summary\": \"network-related environment looks readable\", \"details\": { \"proxy env vars\": \"none\" }, \"remediation\": null, \"durationMs\": 0 }, \"network.provider_reachability\": { \"id\": \"network.provider_reachability\", \"category\": \"reachability\", \"status\": \"ok\", \"summary\": \"active provider endpoints are reachable over HTTP\", \"details\": { \"ChatGPT base URL\": \"https://chatgpt.com/backend-api/ reachable (HTTP 403)\", \"reachability mode\": \"ChatGPT auth\" }, \"remediation\": null, \"durationMs\": 249 }, \"network.websocket_reachability\": { \"id\": \"network.websocket_reachability\", \"category\": \"websocket\", \"status\": \"ok\", \"summary\": \"Responses WebSocket handshake succeeded\", \"details\": { \"DNS\": \"1 IPv4, 1 IPv6, first IPv4\", \"auth mode\": \"chatgpt\", \"connect timeout\": \"15000 ms\", \"endpoint\": \"wss://chatgpt.com/backend-api/\", \"handshake result\": \"HTTP 101 Switching Protocols\", \"model provider\": \"openai\", \"models etag present\": \"true\", \"provider name\": \"OpenAI\", \"proxy env vars\": \"none\", \"reasoning header\": \"false\", \"server model present\": \"false\", \"supports websockets\": \"true\", \"wire API\": \"responses\" }, \"remediation\": null, \"durationMs\": 1401 }, \"runtime.provenance\": { \"id\": \"runtime.provenance\", \"category\": \"runtime\", \"status\": \"ok\", \"summary\": \"running npm on windows-x86_64\", \"details\": { \"commit\": \"unknown\", \"current executable\": \"\", \"install method\": \"npm ()\", \"platform\": \"windows-x86_64\", \"version\": \"0.147.0\" }, \"remediation\": null, \"durationMs\": 1 }, \"runtime.search\": { \"id\": \"runtime.search\", \"category\": \"search\", \"status\": \"ok\", \"summary\": \"search is OK (bundled)\", \"details\": { \"search command\": \"\", \"search command readiness\": \"file exists\", \"search provider\": \"bundled\" }, \"remediation\": null, \"durationMs\": 0 }, \"sandbox.helpers\": { \"id\": \"sandbox.helpers\", \"category\": \"sandbox\", \"status\": \"ok\", \"summary\": \"sandbox configuration is readable\", \"details\": { \"approval policy\": \"Never\", \"codex-linux-sandbox helper\": \"none\", \"execve wrapper helper\": \"none\", \"filesystem sandbox\": \"unrestricted\", \"network sandbox\": \"enabled\" }, \"remediation\": null, \"durationMs\": 0 }, \"state.paths\": { \"id\": \"state.paths\", \"category\": \"state\", \"status\": \"ok\", \"summary\": \"state paths and databases are inspectable\", \"details\": { \"CODEX_HOME\": \" (dir)\", \"active rollout files\": \"326 files, 634326959 total bytes, 1945788 average bytes\", \"archived rollout files\": \"0 files, 0 total bytes, 0 average bytes\", \"goals DB\": \" (file)\", \"goals DB integrity\": \"ok\", \"log DB\": \" (file)\", \"log DB integrity\": \"ok\", \"log dir\": \" (dir)\", \"memories DB\": \" (file)\", \"memories DB integrity\": \"ok\", \"queue DB\": \" (file)\", \"queue DB integrity\": \"ok\", \"sqlite home\": \" (dir)\", \"state DB\": \" (file)\", \"state DB integrity\": \"ok\", \"thread history DB\": \" (file)\", \"thread history DB integrity\": \"ok\" }, \"remediation\": null, \"durationMs\": 18082 }, \"state.rollout_db_parity\": { \"id\": \"state.rollout_db_parity\", \"category\": \"threads\", \"status\": \"warning\", \"summary\": \"rollout files and state DB thread inventory differ\", \"details\": { \"default model provider\": \"openai\", \"rollout DB active files\": \"326\", \"rollout DB active rows\": \"387\", \"rollout DB archive mismatches\": \"0\", \"rollout DB archived files\": \"0\", \"rollout DB archived rows\": \"0\", \"rollout DB duplicate DB paths\": \"0\", \"rollout DB duplicate rollout thread ids\": \"0\", \"rollout DB malformed file names\": \"0\", \"rollout DB missing active rows\": \"0\", \"rollout DB missing archived rows\": \"0\", \"rollout DB model providers\": \"openai=383, =4\", \"rollout DB rows\": \"387\", \"rollout DB scan cap reached\": \"false\", \"rollout DB scan errors\": \"0\", \"rollout DB sources\": \"subagent:thread_spawn=225, subagent:other=74, vscode=36, exec=31, cli=21\", \"rollout DB stale row sample\": [ \"\", \"\", \"\", \"\", \"\" ], \"rollout DB stale rows\": \"61\" }, \"issues\": [ { \"severity\": \"warning\", \"cause\": \"state DB rows point at missing or unusable rollout files\", \"measured\": \"61 stale rows\", \"expected\": \"every state DB rollout path is a file on disk\", \"remedy\": null, \"fields\": [] } ], \"remediation\": null, \"durationMs\": 11623 }, \"system.environment\": { \"id\": \"system.environment\", \"category\": \"system\", \"status\": \"ok\", \"summary\": \"OS language en-US\", \"details\": { \"EDITOR\": \"not set\", \"VISUAL\": \"not set\", \"os\": \"Windows 10.0.26200 (Windows 11 Professional) [64-bit]\", \"os language\": \"en-US\", \"os type\": \"Windows\", \"os version\": \"10.0.26200\" }, \"remediation\": null, \"durationMs\": 8 }, \"terminal.env\": { \"id\": \"terminal.env\", \"category\": \"terminal\", \"status\": \"ok\", \"summary\": \"terminal metadata was detected\", \"details\": { \"WT_SESSION\": \"present\", \"color output\": \"enabled\", \"console input code page\": \"437\", \"console output code page\": \"437\", \"stderr console mode\": \"0x00000007 (VT processing: true)\", \"stderr is terminal\": \"true\", \"stdin is terminal\": \"true\", \"stdout console mode\": \"0x00000007 (VT processing: true)\", \"stdout is terminal\": \"true\", \"terminal\": \"Windows Terminal\", \"terminal size\": \"120x30\" }, \"remediation\": null, \"durationMs\": 1 }, \"terminal.title\": { \"id\": \"terminal.title\", \"category\": \"title\", \"status\": \"ok\", \"summary\": \"terminal title default\", \"details\": { \"terminal title activity\": \"true\", \"terminal title items\": \"activity, project-name\", \"terminal title project source\": \"cwd\", \"terminal title project value\": \"\", \"terminal title source\": \"default\" }, \"remediation\": null, \"durationMs\": 1 }, \"updates.status\": { \"id\": \"updates.status\", \"category\": \"updates\", \"status\": \"warning\", \"summary\": \"update configuration is locally consistent\", \"details\": { \"cached latest version\": \"0.147.0\", \"check for update on startup\": \"true\", \"last checked at\": \"2026-08-09T11:48:19.959694600Z\", \"latest version probe\": \"curl: (28) Operation timed out after 10265 milliseconds with 0 bytes received\", \"npm update target\": \"\", \"update action\": \"npm install -g @openai/codex\", \"version cache\": \"\" }, \"remediation\": null, \"durationMs\": 10771 } } } ``` ### What issue are you seeing? Codex CLI does not appear to provide a way to tag or explicitly invoke a configured subagent from the prompt, even though this workflow is available in the Codex app. In the Codex app, I can explicitly select/tag a particular subagent when I want a task delegated to that agent. In the CLI, I can have subagents configured and Codex may decide to use them autonomously, but I cannot directly tell Codex something equivalent to: @repo-scout inspect the authentication implementation or: Ask @researcher to investigate this dependency. There is no agent autocomplete/mention UI when typing @, and I have not found another CLI syntax that lets me explicitly address one of my configured subagents. This makes custom agents considerably less useful in CLI workflows because I often know which agent I want to handle a particular part of the task and do not want to rely on the parent agent deciding whether and how to delegate it. ### What steps can reproduce the bug? Configure one or more custom/subagents that Codex can use. Open the Codex app and start a session. Use the app's agent-tagging/selection functionality to explicitly direct work to a particular subagent. Open Codex CLI with the same setup. Start typing a prompt and attempt to explicitly reference one of those agents. Type @ or the agent's name. No subagent autocomplete/selection appears, and the agent cannot be explicitly addressed in the same way as in the Codex app. For example: @repo-scout map the parts of this repository involved in authentication. The CLI treats this as ordinary prompt text rather than resolving repo-scout as a configured subagent. ### What is the expected behavior? Codex CLI should support explicit subagent invocation with behavior comparable to the Codex app. Ideally, typing: @ would show configured/available subagents, similar to other CLI autocomplete menus. I should then be able to write something such as: @repo-scout inspect the repository and report which files are relevant. and have Codex explicitly run that task using the selected subagent. It would also be useful for mentions to work inside larger orchestration prompts, for example: @repo-scout find the relevant code, then have @reviewer check the proposed fix. The parent agent should still be free to autonomously spawn/delegate to agents when appropriate. This request is specifically about also giving the user an explicit way to choose a subagent, as is possible in the Codex app. ### Additional information This is especially useful for workflows with specialized custom agents such as: repository scouts code reviewers researchers test/debug agents implementation agents Without explicit addressing, defining several specialized subagents is less predictable from the CLI because the user has to ask the main agent to delegate indirectly and hope it chooses the intended agent. If the app and CLI share the same underlying subagent system, exposing agent mentions/autocomplete in the CLI would make the two interfaces much more consistent", "url": "https://github.com/openai/codex/issues/38215", "createdAt": "2026-08-12T16:40:06Z", "updatedAt": "2026-08-12T16:40:47Z", "timestamp": "2026-08-12T16:40:47Z", "metrics": { "reactions": 0, "comments": 0 }, "labels": [ "bug", "enhancement", "windows-os", "TUI", "CLI", "subagent" ], "author": "sudoax0n", "state": "open", "assignees": [] }, { "id": "github:openai/codex:issue:38216", "source": "github", "group": "coding-agent-infrastructure", "project": "openai/codex", "kind": "issue", "title": "Deep Scan Windows path bug", "text": "### What version of the Codex App are you using (From “About Codex” dialog)? Version 26.803.81509 ### What subscription do you have? Pro 5X ### What platform is your computer? Microsoft Windows NT 10.0.26200.0 x64 ### What issue are you seeing? When running the Codex Security Deep Scan on a Windows checkout, the scan fails immediately during its deterministic setup phase. The failure happens before any source files are reviewed, before discovery workers are started, and before any findings, exploit-chain analysis, or final report can be produced. The issue is caused by a path-format mismatch between the inventory generator and the Deep Scan validator. The inventory generator uses rg --files with the scope . and produces Windows-style relative paths such as: .\\trusted-html.js .\\src\\services\\example.js However, the following validation step only accepts safe repository-relative POSIX paths, such as: trusted-html.js src/services/example.js Because the first generated path contains the .\\ prefix and Windows backslashes, the validator rejects it with: in_scope_files.txt:1 must be a safe repository-relative path As a result, the Deep Scan terminates during setup with zero discovery runs and zero workers. This appears to be a Windows-specific path-normalization issue in the Deep Scan workflow, rather than an issue in the scanned project. ### What steps can reproduce the bug? Feedback ID: 019ff6d0-6414-7a71-9129-9045206322af ### What is the expected behavior? The scan should normalize generated inventory paths to safe repository-relative POSIX paths (for example, src/file.js) and continue with discovery, validation, and report generation. ### Additional information _No response_", "url": "https://github.com/openai/codex/issues/38216", "createdAt": "2026-08-12T16:47:49Z", "updatedAt": "2026-08-12T16:59:50Z", "timestamp": "2026-08-12T16:59:50Z", "metrics": { "reactions": 0, "comments": 1 }, "labels": [ "bug", "windows-os", "app" ], "author": "Ben2248", "state": "open", "assignees": [] }, { "id": "github:openai/codex:issue:38218", "source": "github", "group": "coding-agent-infrastructure", "project": "openai/codex", "kind": "issue", "title": "Add search and filtering to the Projects list in Codex Desktop", "text": "### What variant of Codex are you using? Codex Desktop ### What feature would you like to see? Codex Desktop provides a filter for the Chats/Recents list, but the Projects list has no equivalent filter or search control. As the number of projects grows, it becomes difficult to find and switch to a particular project. This is especially noticeable when using Codex as a quick project switcher rather than only navigating between recent tasks. ### Desired behavior - Add a filter or search control to the Projects section. - Match projects by project name and, where available, folder path. - Keep the filtering interaction consistent with the existing Chats/Recents filter. - Consider options such as All projects, Local projects, Remote projects, and Projects with active chats. - Do not exclude a project merely because it has no existing chat. Selecting such a project should offer to open Codex at that project folder. ### Additional information The Chats/Recents list already demonstrates the filtering interaction that should also be available for Projects.", "url": "https://github.com/openai/codex/issues/38218", "createdAt": "2026-08-12T16:59:51Z", "updatedAt": "2026-08-12T17:00:29Z", "timestamp": "2026-08-12T17:00:29Z", "metrics": { "reactions": 0, "comments": 0 }, "labels": [ "enhancement", "app" ], "author": "codeputer", "state": "open", "assignees": [] }, { "id": "github:openai/codex:issue:38219", "source": "github", "group": "coding-agent-infrastructure", "project": "openai/codex", "kind": "issue", "title": "[Regression][Remote] VS Code and iOS threads no longer sync bidirectionally after VS Code restart", "text": "### What issue are you seeing? Codex Remote no longer keeps the same thread/history visible between VS Code on the PC and the ChatGPT mobile app on iPhone. This previously worked: I could start a Codex chat on the PC, open the same chat on mobile, see live progress, and continue the same conversation from either device. Now the state appears split between devices: - If I start a Codex task/chat in VS Code on the PC, I cannot see its current progress / messages correctly on mobile. - If I start a Codex Remote chat on mobile, it is not visible/resumable in VS Code on the PC after restarting VS Code. - On mobile, opening the affected remote chat can fail with the German error: ```text Fehler beim Laden der Nachrichten: Der Codex-Server hat einen Fehler zurückgegeben. ``` (English: “Error loading messages: The Codex server returned an error.”) This looks like a regression in Remote thread/session indexing or reattachment across clients rather than the intended cross-device Remote behavior. ### Environment - Desktop client: VS Code with Codex / ChatGPT extension - Mobile client: ChatGPT iOS app - iOS: 26.6 - ChatGPT iOS app build observed: 30960470514 - Exact VS Code extension version: not captured yet - Desktop OS/build: not captured yet - Date reproduced: 2026-08-12 ### Steps to reproduce #### PC → mobile 1. Open a project in VS Code and start a Codex task/chat. 2. Let the task continue running / producing progress. 3. Open ChatGPT on iPhone and go to Codex Remote for the same PC/project. 4. Open the corresponding chat. 5. The current task/progress is not reliably visible; in at least one case the mobile app shows `Fehler beim Laden der Nachrichten: Der Codex-Server hat einen Fehler zurückgegeben.` #### Mobile → PC 1. Start a Codex Remote chat/task from the ChatGPT iOS app against the connected PC. 2. Confirm it is usable on mobile. 3. Restart VS Code on the PC. 4. Open the Codex/ChatGPT extension. 5. The mobile-started thread is not visible/resumable there as the same conversation. ### Expected behavior Remote should keep one coherent thread/session across VS Code and the ChatGPT mobile app: - a task started on PC should be visible on mobile with its live/current state; - a task started on mobile should remain visible/resumable in VS Code after restarting VS Code; - both clients should attach to the same thread/history rather than showing different conversation state; - restarting VS Code should not break the cross-device association. ### Regression The same workflow worked previously: the same chat could be used from both mobile and PC and progress was visible across devices. The problem is therefore a regression rather than a request for new functionality. ### Related issues This appears related to prior Remote thread visibility/indexing problems such as #23351, but that issue was closed as completed. It may also overlap with cross-client session divergence reported in #31114. The current symptom is specifically a bidirectional visibility/resume regression involving VS Code + iOS and VS Code restart. ### Additional information A screenshot is available showing the mobile error message. I can provide the exact VS Code extension version, desktop OS/build, Remote host diagnostics, or feedback/session ID if maintainers need them.", "url": "https://github.com/openai/codex/issues/38219", "createdAt": "2026-08-12T17:03:18Z", "updatedAt": "2026-08-12T17:04:52Z", "timestamp": "2026-08-12T17:04:52Z", "metrics": { "reactions": 0, "comments": 1 }, "labels": [ "bug", "extension", "iOS", "session", "remote" ], "author": "tipicoUEFN", "state": "open", "assignees": [] }, { "id": "github:openai/codex:issue:38220", "source": "github", "group": "coding-agent-infrastructure", "project": "openai/codex", "kind": "issue", "title": "Codex desktop viewport jumps and composer overlays text while user is reading scrolled history", "text": "## Summary When reading a Codex desktop task while scrolled above the bottom, the conversation viewport repeatedly jumps/reflows without user input. The floating composer also overlays message content instead of reserving vertical space, hiding the text the user is trying to read. This happened repeatedly in one task while the user was reading prior assistant messages. The user was not interacting with the input/composer when at least one jump occurred. ## Environment - App: Codex desktop / ChatGPT Windows Store package - Package: `OpenAI.Codex_26.803.10989.0_x64__2p2nqsd0c76g0` - Version: `26.803.10989.0` - SignatureKind: Store - OS: Windows, user environment path indicates Windows desktop ## Steps to reproduce 1. Open a long Codex task with enough messages to scroll. 2. Scroll upward to read prior assistant text, not at the bottom. 3. Continue reading while the task/composer is idle, or while new nearby content/layout settles. 4. Observe the viewport unexpectedly jump/reflow. 5. Observe the composer overlaying the message area and hiding text behind the input box. ## Actual behavior - Reading position is not preserved while scrolled above the bottom. - The viewport jumps/reflows repeatedly. - The bottom composer overlays readable message content. - Text being read is pushed under/behind the composer. - A jump-to-bottom affordance is visible, but the app still changes the viewport while the user is reading. ## Expected behavior - If the user is scrolled above the bottom, preserve the scroll anchor. - Do not auto-scroll/reflow the viewport unless the user explicitly jumps to bottom or is already at bottom. - Reserve bottom padding/layout space equal to the composer height. - Never allow the composer to cover message text. - If new messages/content arrive while the user is scrolled up, show a non-disruptive “new message” affordance. ## Suggested implementation direction - Track whether the scroll container is near bottom before content/composer size changes. - If not near bottom, preserve the currently visible message/scroll anchor through layout changes. - If near bottom, continue auto-scroll behavior. - Ensure the message list has bottom padding equal to the composer height rather than relying on overlay behavior. Pseudo behavior: ```js const wasAtBottom = isNearBottom(scrollContainer) onContentOrComposerResize(() => { if (wasAtBottom) scrollToBottom() else preserveScrollAnchor() }) ``` ## Screenshots captured locally The user provided screenshots showing the composer covering message text and the reading viewport jumping: - `C:/Users/mattr/AppData/Local/Temp/codex-clipboard-1cdf1cbd-35da-41ad-a1d7-84bc85ec9905.png` - `C:/Users/mattr/AppData/Local/Temp/codex-clipboard-e1f7a3ab-068b-4a33-b6ec-b6406e859f6c.png` - `C:/Users/mattr/AppData/Local/Temp/codex-clipboard-9591ef57-eb5b-4b3c-96fe-49357eb7f09a.png` I cannot attach those local files through this connector, but they demonstrate the issue clearly: the composer floats over the lower message text while the user is scrolled up and reading.", "url": "https://github.com/openai/codex/issues/38220", "createdAt": "2026-08-12T17:04:08Z", "updatedAt": "2026-08-12T17:05:40Z", "timestamp": "2026-08-12T17:05:40Z", "metrics": { "reactions": 0, "comments": 2 }, "labels": [ "bug", "windows-os", "app" ], "author": "mattrdell", "state": "open", "assignees": [] }, { "id": "github:openai/codex:issue:38221", "source": "github", "group": "coding-agent-infrastructure", "project": "openai/codex", "kind": "issue", "title": "Allow async Stop to start a same-session continuation (KV cache)", "text": "## What we are trying [knowcards](https://github.com/manojbajaj95/agent-knowledge-cards) captures durable repo facts at end of turn. The reflect step must run on the **same session id and message history** so the model reuses KV cache. A separate worker/LLM (truncated transcript) throws that cache away. We want that continuation **after** the user-facing turn ends (background / idle wake), not as a fake user message in the middle of the answer. ## What Codex does today - Sync `Stop` + `decision: \\\"block\\\"` + `reason` works: Codex creates a **new user prompt** from `reason` and continues the same session. That keeps KV cache, but it is a user-channel message and it runs immediately. - Docs: a background hook that finishes while **no turn is active** waits for the next user turn and **does not start a new turn**. - Related: async command hooks may still be skipped at load ([#34694](https://github.com/openai/codex/issues/34694)). So we cannot both (1) stay on this session for KV cache and (2) defer reflect until the UI has stopped. ## Request Let an async `Stop` handler start a **same-session** continuation when it returns `decision: \\\"block\\\"` + `reason` (or `hookSpecificOutput.additionalContext` as developer context, not a user prompt). Ideal shape: - Same `session_id` / transcript prefix (KV cache hits). - Not a user-visible chat bubble (developer / system reminder). - May start after the user-facing turn is idle (wake), instead of only attaching to the next human prompt. ## Workaround in knowcards `knowcards install codex` keeps Stop **synchronous** for now. Adapter: [`src/adapters/codex-reflect.ts`](https://github.com/manojbajaj95/agent-knowledge-cards/blob/refactor/core/src/adapters/codex-reflect.ts) Claude Code has `asyncRewake` (exit 2 wakes the idle session). We use that there. Codex has no equivalent.", "url": "https://github.com/openai/codex/issues/38221", "createdAt": "2026-08-12T17:07:06Z", "updatedAt": "2026-08-12T17:07:47Z", "timestamp": "2026-08-12T17:07:47Z", "metrics": { "reactions": 0, "comments": 0 }, "labels": [ "enhancement", "CLI", "hooks", "session" ], "author": "manojbajaj95", "state": "open", "assignees": [] }, { "id": "github:openai/codex:issue:38222", "source": "github", "group": "coding-agent-infrastructure", "project": "openai/codex", "kind": "issue", "title": "Windows sandbox: restricted token cannot enumerate or execute under the user profile, so pwsh/python/gh silently \"do not exist\"", "text": "**What version of Codex CLI is running?** `codex-cli 0.146.1` (`@openai/codex` 0.146.1, `codex-win32-x64`) **What subscription do you have?** ChatGPT (`auth_mode = chatgpt`) **Which model were you using?** `gpt-5.6-sol` **What platform is your computer?** `Microsoft Windows NT 10.0.26200.9168 x64` **What terminal emulator?** Reproduced from Git Bash (MSYS2) and `cmd.exe`; not terminal-specific. **Codex doctor report:** `17 ok · 1 idle · 1 notes · 0 warn · 0 fail` — auth, connectivity and model access are all healthy. The failure is entirely in the sandbox command runner. --- ## What issue are you seeing? On this machine the Windows sandbox's restricted token **can stat paths under `C:\\Users\\\\` but cannot enumerate directories or execute binaries there.** Sandboxed `codex exec` is consequently unable to run any tool installed under the user profile — which on a normal Windows dev box is most of them. It surfaces as two unrelated-looking symptoms with one cause. ### Symptom 1 — total `CreateProcessAsUserW failed: 5` when `pwsh` is an MSIX App Execution Alias ``` windows sandbox: runner failed during SpawnChild: CreateProcessAsUserW failed: 5 (Access is denied.) | cwd=C:\\Users\\\\dev\\ | cmd=C:\\Users\\\\AppData\\Local\\Microsoft\\WindowsApps\\pwsh.exe -NoProfile -Command \"...\" | env_u16_len=5450 | si_flags=256 | creation_flags=525312 (Windows error 5) ``` The `cmd=` path is under the user profile. `…\\AppData\\Local\\Microsoft\\WindowsApps\\pwsh.exe` is an App Execution Alias — a reparse point into `C:\\Program Files\\WindowsApps\\Microsoft.PowerShell_7.6.4.0_x64__8wekyb3d8bbwe\\pwsh.exe` — and the sandbox token cannot execute it. Every command fails before it runs, under both `-s read-only` and `-s workspace-write`. This is a common configuration rather than an exotic one: `winget install --id Microsoft.PowerShell` installs the **msix** variant, and that is the only installer in the manifest. ``` > winget show --id Microsoft.PowerShell --exact Version: 7.6.4.0 Installer Type: msix Installer Url: .../PowerShell-7.6.4.msixbundle ``` So anyone who installed PowerShell 7 via winget and never separately ran the MSI has `pwsh` on PATH as an alias only, with `C:\\Program Files\\PowerShell\\7\\pwsh.exe` absent. `winget install --installer-type msi --force` cannot help — it returns `No applicable installer found`, because the manifest has no MSI. **Workaround for this half:** remove `WindowsApps` from the PATH **the `codex` process itself** sees. Shell discovery then falls through its candidate list (`pwsh` → `pwsh.exe` → `powershell` → `powershell.exe`) to Windows PowerShell 5.1 at `C:\\Windows\\System32\\WindowsPowerShell\\v1.0\\powershell.exe`, which is machine-wide, and commands spawn correctly. ### Symptom 2 — with a machine-wide shell, every user-profile tool reports \"not recognized\" After that workaround the sandbox runs commands, but only machine-wide ones. `git` (at `C:\\Program Files\\Git`) works; `python` and `gh` do not: ``` gh : The term 'gh' is not recognized as the name of a cmdlet, function, script file, or operable program. python : The term 'python' is not recognized as the name of a cmdlet, function, script file, or operable program. ``` **This is not a PATH problem.** I initially assumed it was and was wrong. Dumping `$env:PATH` from inside the sandbox shows the inherited PATH arrives intact, including both directories: ``` C:\\Users\\\\.codex\\tmp\\arg0\\codex-arg0CGD0Ky C:\\Users\\\\AppData\\Roaming\\npm\\...\\codex-win32-x64\\vendor\\...\\codex-path C:\\Program Files\\Git\\mingw64\\bin ... C:\\Users\\\\AppData\\Local\\Programs\\Python\\Python312 <-- present ... C:\\Users\\\\AppData\\Local\\Microsoft\\WinGet\\Links <-- present ``` `shell_environment_policy` also works correctly — arbitrary variables set via `-c shell_environment_policy.set.FOO=bar` arrive in the child exactly as configured. Neither mechanism is at fault. ### The actual cause, probed directly Run inside the sandbox (`-s workspace-write`, machine-wide PowerShell): ```powershell $p = \"C:\\Users\\\\AppData\\Local\\Programs\\Python\\Python312\\python.exe\" $g = \"C:\\Program Files\\Git\\cmd\\git.exe\" Test-Path -LiteralPath $p # -> True Test-Path -LiteralPath $g # -> True Get-ChildItem -LiteralPath (Split-Path $p) # -> UnauthorizedAccessException & $p -c \"print(42)\" # -> ApplicationFailedException ``` The token can **stat** the user-profile executable, but cannot **enumerate** its directory and cannot **execute** it. The machine-wide binary is fine. That single fact produces both symptoms: `pwsh` fails to spawn because the alias is in the profile, and `python`/`gh` are \"not found\" because PowerShell's command discovery cannot enumerate the PATH directories holding them. Writes to the workspace itself succeed under `-s workspace-write` even though the workspace is also under `C:\\Users\\\\`, so this is not a blanket profile denial — execute and enumerate are denied where write is allowed. `-s danger-full-access` is unaffected, since it does not use the sandbox runner: ``` > codex exec -s danger-full-access 'run: git rev-parse --short HEAD; gh --version; python -c \"print(1+1)\"' 90756b1 gh version 2.95.0 (2026-06-17) 2 ``` ## What steps can reproduce the bug? 1. Windows 11. Install PowerShell 7 with `winget install --id Microsoft.PowerShell` (yields msix). Confirm `C:\\Program Files\\PowerShell\\7\\pwsh.exe` does not exist and `where pwsh` returns the `WindowsApps` path. 2. Install any tool into the user profile — e.g. `winget install GitHub.cli`, or python.org's per-user Python. 3. `codex exec -s read-only 'run: git rev-parse --short HEAD'` → every command fails with `CreateProcessAsUserW failed: 5`, `cmd=` pointing at the WindowsApps alias. 4. Re-run with `WindowsApps` removed from the PATH the `codex` process sees → commands now spawn via `powershell.exe`, and `git` works. 5. `codex exec -s workspace-write 'run: gh --version'` → `not recognized`, despite `WinGet\\Links` being present in the sandbox's `$env:PATH`. 6. Run the `Test-Path` / `Get-ChildItem` / full-path-execute probe above → `True`, `UnauthorizedAccessException`, `ApplicationFailedException`. ## What is the expected behavior? 1. **The sandbox should be able to execute the user's toolchain.** Per-user installs are the norm on Windows — winget package links, python.org per-user installs, npm globals, pipx, rustup, Store apps. If the token cannot execute anything under `C:\\Users\\\\`, sandboxed mode cannot run most real projects, and `-s danger-full-access` becomes the only usable setting, which defeats the point of having a sandbox. 2. **If this denial is deliberate isolation, it needs to say so.** Right now a denied execute is reported as `CommandNotFoundException` — \"the term 'python' is not recognized\" — which sends you looking for a PATH bug. I spent a long time ruling out PATH, `shell_environment_policy.inherit`, `set.PATH`, and profile files before probing the ACL. An explicit \"sandbox denied execute on ``\" would have made it a one-minute diagnosis, and the docs should state that user-profile executables are unavailable in sandboxed mode. 3. **Shell discovery should not select an executable the sandbox's own token cannot start.** Skipping WindowsApps alias stubs, or probing the machine-wide `C:\\Program Files\\PowerShell\\7\\pwsh.exe` (already referenced in the binary) before the PATH lookup, would fix symptom 1 outright. ## Relationship to existing issues #26186, #37592, #30024, #35958 and #36614 all report `CreateProcessAsUserW` failures, the first two with error 5. **I am not claiming those share this cause.** #37592's follow-up describes an *intermittent* failure where some commands succeed, correlated with `SetFileAttributesW` on `C:\\Users\\Default`; this one is total, deterministic, and fully explained by the token's inability to execute under the user profile. Filing separately rather than assuming — if a maintainer confirms a shared root cause, please close this as a duplicate. Found while trying to run a code review with `codex exec` on an ordinary developer machine; nothing here is specific to the project under review. Paths redacted per the template.", "url": "https://github.com/openai/codex/issues/38222", "createdAt": "2026-08-12T17:11:35Z", "updatedAt": "2026-08-12T17:13:02Z", "timestamp": "2026-08-12T17:13:02Z", "metrics": { "reactions": 0, "comments": 1 }, "labels": [ "bug", "windows-os", "sandbox", "exec", "CLI" ], "author": "jrgoralski", "state": "open", "assignees": [] }, { "id": "github:openai/codex:issue:38223", "source": "github", "group": "coding-agent-infrastructure", "project": "openai/codex", "kind": "issue", "title": "[Windows Desktop] Existing local project threads show “No chats” but remain intact and resumable by thread ID", "text": "Closing this public report because I prefer to continue troubleshooting through a private OpenAI Support channel. The issue contains local project/environment details that I do not want to keep published publicly. OpenAI maintainers: if possible, please remove or redact this issue from public view. I will provide the technical diagnostics privately to Support.", "url": "https://github.com/openai/codex/issues/38223", "createdAt": "2026-08-12T17:23:46Z", "updatedAt": "2026-08-12T17:26:54Z", "timestamp": "2026-08-12T17:26:54Z", "metrics": { "reactions": 0, "comments": 1 }, "labels": [ "bug", "windows-os", "app", "session" ], "author": "SoftwarePartnerDenmark", "state": "closed", "assignees": [] }, { "id": "github:openai/codex:issue:38224", "source": "github", "group": "coding-agent-infrastructure", "project": "openai/codex", "kind": "issue", "title": "/MCP command returns raw results in CLI", "text": "### What version of Codex CLI is running? codex-cli 0.147.0 ### What subscription do you have? Business ### Which model were you using? gpt-5.6-sol medium ### What platform is your computer? Windows 11 ### What terminal emulator and version are you using (if applicable)? Powershell ### Codex doctor report ```json { \"schemaVersion\": 1, \"generatedAt\": \"1786555600s since unix epoch\", \"overallStatus\": \"ok\", \"codexVersion\": \"0.147.0\", \"checks\": { \"app_server.status\": { \"id\": \"app_server.status\", \"category\": \"app-server\", \"status\": \"ok\", \"summary\": \"background server is not running\", \"details\": { \"control socket\": \"C:\\\\Users\\\\chris\\\\.codex\\\\app-server-control\\\\app-server-control.sock\", \"daemon state dir\": \"C:\\\\Users\\\\chris\\\\.codex\\\\app-server-daemon\", \"mode\": \"ephemeral\", \"pid file\": \"C:\\\\Users\\\\chris\\\\.codex\\\\app-server-daemon\\\\app-server.pid (missing)\", \"settings\": \"C:\\\\Users\\\\chris\\\\.codex\\\\app-server-daemon\\\\settings.json (missing)\", \"status\": \"not running\", \"update-loop pid file\": \"C:\\\\Users\\\\chris\\\\.codex\\\\app-server-daemon\\\\app-server-updater.pid (missing)\" }, \"remediation\": null, \"durationMs\": 0 }, \"auth.credentials\": { \"id\": \"auth.credentials\", \"category\": \"auth\", \"status\": \"ok\", \"summary\": \"auth is configured\", \"details\": { \"auth file\": \"C:\\\\Users\\\\chris\\\\.codex\\\\auth.json\", \"auth storage mode\": \"File\", \"stored API key\": \"false\", \"stored ChatGPT tokens\": \"true\", \"stored agent identity\": \"false\", \"stored auth mode\": \"chatgpt\" }, \"remediation\": null, \"durationMs\": 0 }, \"config.load\": { \"id\": \"config.load\", \"category\": \"config\", \"status\": \"ok\", \"summary\": \"config loaded\", \"details\": { \"CODEX_HOME\": \"C:\\\\Users\\\\chris\\\\.codex\", \"config.toml\": \"C:\\\\Users\\\\chris\\\\.codex\\\\config.toml\", \"config.toml parse\": \"ok\", \"cwd\": \"C:\\\\Users\\\\chris\", \"enabled feature flags\": \"\", \"feature flag overrides\": \"none\", \"feature flags enabled\": \"39\", \"log dir\": \"C:\\\\Users\\\\chris\\\\.codex\\\\log\", \"mcp servers\": \"1\", \"model\": \"gpt-5.6-sol\", \"model provider\": \"openai\", \"sqlite home\": \"C:\\\\Users\\\\chris\\\\.codex\" }, \"remediation\": null, \"durationMs\": 0 }, \"git.environment\": { \"id\": \"git.environment\", \"category\": \"git\", \"status\": \"ok\", \"summary\": \"git version 2.55.0.windows.3\", \"details\": { \"PATH git #1\": \"C:\\\\Program Files\\\\Git\\\\cmd\\\\git.exe\", \"PATH git entries\": \"1\", \"git build options\": \"git version 2.55.0.windows.3; cpu: x86_64; built from commit: 52ca1113d651127f89477a8763f86ab20f645e1d; sizeof-long: 4; sizeof-size_t: 8; shell-path: D:/git-sdk-64/usr/bin/sh; rust: disabled; feature: fsmonitor--daemon; gettext: enabled; libcurl: 8.21.0; OpenSSL: OpenSSL 3.5.7 9 Jun 2026; zlib: 1.3.2; SHA-1: SHA1_DC; SHA-256: SHA256_BLK; default-ref-format: files; default-hash: sha1\", \"git exec path\": \"C:/Program Files/Git/mingw64/libexec/git-core\", \"git version\": \"git version 2.55.0.windows.3\", \"repo detected\": \"false\", \"selected git\": \"C:\\\\Program Files\\\\Git\\\\cmd\\\\git.exe\" }, \"remediation\": null, \"durationMs\": 45 }, \"installation\": { \"id\": \"installation\", \"category\": \"install\", \"status\": \"ok\", \"summary\": \"installation looks consistent\", \"details\": { \"PATH codex #1\": \"C:\\\\Users\\\\chris\\\\AppData\\\\Local\\\\Programs\\\\OpenAI\\\\Codex\\\\bin\\\\codex.exe\", \"PATH codex #2\": \"C:\\\\Users\\\\chris\\\\AppData\\\\Local\\\\Programs\\\\OpenAI Codex CLI\\\\codex.exe\", \"PATH codex #3\": \"C:\\\\Users\\\\chris\\\\AppData\\\\Roaming\\\\npm\\\\codex\", \"PATH codex #4\": \"C:\\\\Users\\\\chris\\\\AppData\\\\Roaming\\\\npm\\\\codex.cmd\", \"PATH codex entries\": \"4\", \"current executable\": \"C:\\\\Users\\\\chris\\\\AppData\\\\Local\\\\Programs\\\\OpenAI\\\\Codex\\\\bin\\\\codex.exe\", \"install context\": \"standalone (windows, package C:\\\\Users\\\\chris\\\\.codex\\\\packages\\\\standalone\\\\releases\\\\0.147.0-x86_64-pc-windows-msvc, bin C:\\\\Users\\\\chris\\\\.codex\\\\packages\\\\standalone\\\\releases\\\\0.147.0-x86_64-pc-windows-msvc\\\\bin, resources C:\\\\Users\\\\chris\\\\.codex\\\\packages\\\\standalone\\\\releases\\\\0.147.0-x86_64-pc-windows-msvc\\\\codex-resources, path C:\\\\Users\\\\chris\\\\.codex\\\\packages\\\\standalone\\\\releases\\\\0.147.0-x86_64-pc-windows-msvc\\\\codex-path)\", \"managed by bun\": \"false\", \"managed by npm\": \"false\", \"managed by pnpm\": \"false\", \"managed package root\": \"not set\" }, \"remediation\": null, \"durationMs\": 28 }, \"mcp.config\": { \"id\": \"mcp.config\", \"category\": \"mcp\", \"status\": \"ok\", \"summary\": \"MCP configuration is locally consistent\", \"details\": { \"configured servers\": \"1\", \"disabled servers\": \"0\", \"stdio servers\": \"1\" }, \"remediation\": null, \"durationMs\": 0 }, \"network.env\": { \"id\": \"network.env\", \"category\": \"network\", \"status\": \"ok\", \"summary\": \"network-related environment looks readable\", \"details\": { \"proxy env vars\": \"none\" }, \"remediation\": null, \"durationMs\": 0 }, \"network.provider_reachability\": { \"id\": \"network.provider_reachability\", \"category\": \"reachability\", \"status\": \"ok\", \"summary\": \"active provider endpoints are reachable over HTTP\", \"details\": { \"ChatGPT base URL\": \"https://chatgpt.com/backend-api/ reachable (HTTP 403)\", \"reachability mode\": \"ChatGPT auth\" }, \"remediation\": null, \"durationMs\": 71 }, \"network.websocket_reachability\": { \"id\": \"network.websocket_reachability\", \"category\": \"websocket\", \"status\": \"ok\", \"summary\": \"Responses WebSocket handshake succeeded\", \"details\": { \"DNS\": \"2 IPv4, 0 IPv6, first IPv4\", \"auth mode\": \"chatgpt\", \"connect timeout\": \"15000 ms\", \"endpoint\": \"wss://chatgpt.com/backend-api/\", \"handshake result\": \"HTTP 101 Switching Protocols\", \"model provider\": \"openai\", \"models etag present\": \"true\", \"provider name\": \"OpenAI\", \"proxy env vars\": \"none\", \"reasoning header\": \"false\", \"server model present\": \"false\", \"supports websockets\": \"true\", \"wire API\": \"responses\" }, \"remediation\": null, \"durationMs\": 552 }, \"runtime.provenance\": { \"id\": \"runtime.provenance\", \"category\": \"runtime\", \"status\": \"ok\", \"summary\": \"running standalone on windows-x86_64\", \"details\": { \"commit\": \"unknown\", \"current executable\": \"C:\\\\Users\\\\chris\\\\AppData\\\\Local\\\\Programs\\\\OpenAI\\\\Codex\\\\bin\\\\codex.exe\", \"install method\": \"standalone (windows, package C:\\\\Users\\\\chris\\\\.codex\\\\packages\\\\standalone\\\\releases\\\\0.147.0-x86_64-pc-windows-msvc, bin C:\\\\Users\\\\chris\\\\.codex\\\\packages\\\\standalone\\\\releases\\\\0.147.0-x86_64-pc-windows-msvc\\\\bin, resources C:\\\\Users\\\\chris\\\\.codex\\\\packages\\\\standalone\\\\releases\\\\0.147.0-x86_64-pc-windows-msvc\\\\codex-resources, path C:\\\\Users\\\\chris\\\\.codex\\\\packages\\\\standalone\\\\releases\\\\0.147.0-x86_64-pc-windows-msvc\\\\codex-path)\", \"platform\": \"windows-x86_64\", \"version\": \"0.147.0\" }, \"remediation\": null, \"durationMs\": 0 }, \"runtime.search\": { \"id\": \"runtime.search\", \"category\": \"search\", \"status\": \"ok\", \"summary\": \"search is OK (bundled)\", \"details\": { \"search command\": \"C:\\\\Users\\\\chris\\\\.codex\\\\packages\\\\standalone\\\\releases\\\\0.147.0-x86_64-pc-windows-msvc\\\\codex-path\\\\rg.exe\", \"search command readiness\": \"file exists\", \"search provider\": \"bundled\" }, \"remediation\": null, \"durationMs\": 0 }, \"sandbox.helpers\": { \"id\": \"sandbox.helpers\", \"category\": \"sandbox\", \"status\": \"ok\", \"summary\": \"sandbox configuration is readable\", \"details\": { \"approval policy\": \"Never\", \"codex-linux-sandbox helper\": \"none\", \"execve wrapper helper\": \"none\", \"filesystem sandbox\": \"restricted\", \"network sandbox\": \"restricted\" }, \"remediation\": null, \"durationMs\": 0 }, \"state.paths\": { \"id\": \"state.paths\", \"category\": \"state\", \"status\": \"ok\", \"summary\": \"state paths and databases are inspectable\", \"details\": { \"CODEX_HOME\": \"C:\\\\Users\\\\chris\\\\.codex (dir)\", \"active rollout files\": \"17 files, 17849009 total bytes, 1049941 average bytes\", \"archived rollout files\": \"1 files, 207604 total bytes, 207604 average bytes\", \"goals DB\": \"C:\\\\Users\\\\chris\\\\.codex\\\\goals_1.sqlite (file)\", \"goals DB integrity\": \"ok\", \"log DB\": \"C:\\\\Users\\\\chris\\\\.codex\\\\logs_2.sqlite (file)\", \"log DB integrity\": \"ok\", \"log dir\": \"C:\\\\Users\\\\chris\\\\.codex\\\\log (missing)\", \"memories DB\": \"C:\\\\Users\\\\chris\\\\.codex\\\\memories_1.sqlite (file)\", \"memories DB integrity\": \"ok\", \"queue DB\": \"C:\\\\Users\\\\chris\\\\.codex\\\\queue_1.sqlite (file)\", \"queue DB integrity\": \"ok\", \"sqlite home\": \"C:\\\\Users\\\\chris\\\\.codex (dir)\", \"standalone release cache\": \"1 entries in C:\\\\Users\\\\chris\\\\.codex\\\\packages\\\\standalone\\\\releases\", \"state DB\": \"C:\\\\Users\\\\chris\\\\.codex\\\\state_5.sqlite (file)\", \"state DB integrity\": \"ok\", \"thread history DB\": \"C:\\\\Users\\\\chris\\\\.codex\\\\thread_history_1.sqlite (file)\", \"thread history DB integrity\": \"ok\" }, \"remediation\": null, \"durationMs\": 77 }, \"state.rollout_db_parity\": { \"id\": \"state.rollout_db_parity\", \"category\": \"threads\", \"status\": \"ok\", \"summary\": \"rollout files and state DB thread inventory agree\", \"details\": { \"default model provider\": \"openai\", \"rollout DB active files\": \"17\", \"rollout DB active rows\": \"17\", \"rollout DB archive mismatches\": \"0\", \"rollout DB archived files\": \"1\", \"rollout DB archived rows\": \"1\", \"rollout DB duplicate DB paths\": \"0\", \"rollout DB duplicate rollout thread ids\": \"0\", \"rollout DB malformed file names\": \"0\", \"rollout DB missing active rows\": \"0\", \"rollout DB missing archived rows\": \"0\", \"rollout DB model providers\": \"openai=18\", \"rollout DB rows\": \"18\", \"rollout DB scan cap reached\": \"false\", \"rollout DB scan errors\": \"0\", \"rollout DB sources\": \"vscode=10, cli=6, exec=1, subagent:other=1\", \"rollout DB stale rows\": \"0\" }, \"remediation\": null, \"durationMs\": 15 }, \"system.environment\": { \"id\": \"system.environment\", \"category\": \"system\", \"status\": \"ok\", \"summary\": \"OS language en-US\", \"details\": { \"EDITOR\": \"not set\", \"VISUAL\": \"not set\", \"os\": \"Windows 10.0.26200 (Windows 11 Professional) [64-bit]\", \"os language\": \"en-US\", \"os type\": \"Windows\", \"os version\": \"10.0.26200\" }, \"remediation\": null, \"durationMs\": 0 }, \"terminal.env\": { \"id\": \"terminal.env\", \"category\": \"terminal\", \"status\": \"ok\", \"summary\": \"terminal metadata was detected\", \"details\": { \"WT_SESSION\": \"present\", \"color output\": \"enabled\", \"console input code page\": \"437\", \"console output code page\": \"437\", \"stderr console mode\": \"0x00000007 (VT processing: true)\", \"stderr is terminal\": \"true\", \"stdin is terminal\": \"true\", \"stdout console mode\": \"0x00000007 (VT processing: true)\", \"stdout is terminal\": \"true\", \"terminal\": \"Windows Terminal\", \"terminal size\": \"270x72\" }, \"remediation\": null, \"durationMs\": 0 }, \"terminal.title\": { \"id\": \"terminal.title\", \"category\": \"title\", \"status\": \"ok\", \"summary\": \"terminal title default\", \"details\": { \"terminal title activity\": \"true\", \"terminal title items\": \"activity, project-name\", \"terminal title project source\": \"cwd\", \"terminal title project value\": \"chris\", \"terminal title source\": \"default\" }, \"remediation\": null, \"durationMs\": 0 }, \"updates.status\": { \"id\": \"updates.status\", \"category\": \"updates\", \"status\": \"ok\", \"summary\": \"update configuration is locally consistent\", \"details\": { \"cached latest version\": \"0.147.0\", \"check for update on startup\": \"true\", \"last checked at\": \"2026-08-12T15:34:10.426386100Z\", \"latest version\": \"0.147.0\", \"latest version status\": \"current version is not older\", \"update action\": \"standalone installer\", \"version cache\": \"C:\\\\Users\\\\chris\\\\.codex\\\\version.json\" }, \"remediation\": null, \"durationMs\": 550 } } } ``` ### What issue are you seeing? Title: /mcp status output is unreadable when many plugin tools are enabled Product and environment: - Codex CLI/TUI: 0.147.0 - Codex desktop-bundled engine: 0.147.0-alpha.6.6 - Operating system: Windows - MCP servers: codex_apps and node_repl - Active plugins/connectors include GitHub, Gmail, Google Calendar, Google Drive, Linear, Slack, Browser, Documents, PDF, Presentations, Spreadsheets, Sites, and others. Problem: Running the built-in `/mcp` slash command produces a very large, poorly structured status display. Authentication labels, tools, resources, and resource templates are rendered as long inline sections. With hundreds of tools exposed by codex_apps, the output becomes an unreadable wall of text. The display includes labels such as: - Auth: Not logged in - Bearer token - Tools - Resources - Resource templates “Bearer token” appears to be an authentication-method label rather than an exposed credential, but its placement is confusing and makes the output look as though authentication data is mixed into the tool list. Expected behavior: The `/mcp` view should present each server as a clearly separated, readable block. For example: Server: codex_apps Status: Connected Authentication: [concise status] Tools: 361 available Resources: 0 Resource templates: 0 [Expand or search tools] Server: node_repl Status: Connected Transport: STDIO Authentication: Not applicable Tools: 3 available Resources: 0 Resource templates: 0 Large tool catalogs should be collapsed, paginated, searchable, or summarized by count. Authentication status should be visually separated from tool names. Credential values must remain redacted. Actual behavior: The complete tool catalog is printed inline alongside authentication and resource information. The result is difficult to scan, wraps badly, and makes the relationship between servers, authentication methods, and tools unclear. Reproduction steps: 1. Enable plugins/connectors that expose a large number of tools. 2. Ensure codex_apps and node_repl are connected. 3. Open a Codex chat. 4. Enter `/mcp`. 5. Observe that the complete tool catalog and authentication labels are rendered in a long, hard-to-read layout. Diagnostic findings: - `codex_apps` and `node_repl` initialize successfully. - MCP tool calls execute successfully. - The node_repl MCP process remains running. - An independent MCP initialization handshake succeeds using protocol version 2025-06-18. - Logs show zero unavailable MCP servers after successful initialization. - This is reproducible after starting a new thread and restarting Codex. - The problem is specific to the built-in `/mcp` presentation; it is not an MCP connectivity failure. - The MCP server responses themselves are valid. - There are two installed Codex executables, but `/mcp` is rendered by the Codex client, and reinstalling the standalone CLI would not address this UI path. Suggested improvements: 1. Group output by MCP server. 2. Show connection and authentication status as dedicated fields. 3. Summarize tools, resources, and templates with counts. 4. Collapse large tool lists by default. 5. Add expansion, paging, filtering, or search. 6. Display “Not applicable” for authentication on local STDIO servers instead of “Unsupported.” 7. Clearly distinguish an authentication-method label such as “Bearer token” from an actual configured credential. 8. Preserve redaction for all secrets. 9. Handle terminal/window width and line wrapping gracefully. 10. Avoid showing a stale “MCP startup interrupted” banner after all servers subsequently initialize successfully. Please review both the `/mcp` status renderer and the handling of transient startup-state updates. I am including logs with this feedback. ### What steps can reproduce the bug? Uploaded thread: 019ff6ec-d547-7c02-a9e3-c05d737e1538 ### What is the expected behavior? Show the MCP servers in a readable form. ### Additional information Using the /MCP command in the CLI should show a readable list of MCP, not the raw response from the server.", "url": "https://github.com/openai/codex/issues/38224", "createdAt": "2026-08-12T17:28:51Z", "updatedAt": "2026-08-12T17:29:31Z", "timestamp": "2026-08-12T17:29:31Z", "metrics": { "reactions": 0, "comments": 0 }, "labels": [ "bug", "enhancement", "windows-os", "mcp", "TUI", "CLI" ], "author": "ChrisSwain-RV", "state": "open", "assignees": [] }, { "id": "github:openai/codex:issue:38225", "source": "github", "group": "coding-agent-infrastructure", "project": "openai/codex", "kind": "issue", "title": "Computer Use / node_repl: nodeRepl.write and nodeRepl.emitImage execute but MCP content[] (screenshots) not surfaced to model", "text": "### What version of the Codex App are you using (From “About Codex” dialog)? Powered by Codex & OWL Version 26.803.81509, Released Aug 11, 2026 ### What subscription do you have? Plus ### What platform is your computer? Microsoft Windows NT 10.0.26200.0 x64 ### What issue are you seeing? Computer Use tool calls to @oai/sky run, and nodeRepl.write / nodeRepl.emitImage appear to execute successfully. However, the tool output visible to the assistant only shows metadata or no payload at all — the actual image content is missing. As a result, Computer Use cannot inspect screenshots b [computer-use-screenshot-bug-report.md](https://github.com/user-attachments/files/30991348/computer-use-screenshot-bug-report.md) ecause the content[] array returned by node_repl over MCP is not being surfaced to the model. ### What steps can reproduce the bug? Start a Computer Use session using @oai/sky. Call nodeRepl.write or nodeRepl.emitImage to emit a screenshot/image. Observe that the call executes without error. Inspect the tool output available to the model — only metadata (or nothing) appears instead of the image payload. ### What is the expected behavior? The content[] array returned by node_repl over MCP (including image/screenshot payloads from emitImage) should be surfaced to the model, so Computer Use can actually inspect the screenshot rather than just metadata. ### Additional information _No response_", "url": "https://github.com/openai/codex/issues/38225", "createdAt": "2026-08-12T17:37:26Z", "updatedAt": "2026-08-13T14:24:37Z", "timestamp": "2026-08-13T14:24:37Z", "metrics": { "reactions": 0, "comments": 2 }, "labels": [ "bug", "windows-os", "mcp", "tool-calls", "app", "computer-use" ], "author": "paneerchilly", "state": "open", "assignees": [] }, { "id": "github:openai/codex:issue:38226", "source": "github", "group": "coding-agent-infrastructure", "project": "openai/codex", "kind": "issue", "title": "Chat status incorrectly showed an old branch (already merged) & merge conflicts message", "text": "### What version of the Codex App are you using (From “About Codex” dialog)? 26.803.61601 ### What subscription do you have? Pro 5x ### What platform is your computer? macOS Darwin 27.0.0 arm64 arm ### What issue are you seeing? In all current and new chats in Codex, they're incorrectly listing a branch \"Test-2\" that was merged on April 22, 2026. It also indicated that there's merge conflicts when there are no branches left, everything had been successfully merged. I've attemped those fixes: • Commit & push everything • Created a new branch then merged it • Created a new PR then merged it Possible cause: A few weeks ago I accidentally created a new PR via Claude Code mac app. I've merged that branch but somehow it messed up Codex. I haven't been able to reproduce or undo this bug. \"Image\" ### What steps can reproduce the bug? Unknown if this is actually the cause but here's what I think was the cause: Both Codex and Claude Code opened (mac apps) Both have a chat building something on the same code project I clicked on \"Create PR\" button in Claude Code and accepted it At some point afterward I noticed Codex started showing old branch & merge conflicts message in all its chats. ### What is the expected behavior? _No response_ ### Additional information _No response_", "url": "https://github.com/openai/codex/issues/38226", "createdAt": "2026-08-12T17:38:24Z", "updatedAt": "2026-08-12T17:39:40Z", "timestamp": "2026-08-12T17:39:40Z", "metrics": { "reactions": 0, "comments": 1 }, "labels": [ "bug", "app", "session" ], "author": "adambetts", "state": "open", "assignees": [] }, { "id": "github:openai/codex:issue:38229", "source": "github", "group": "coding-agent-infrastructure", "project": "openai/codex", "kind": "issue", "title": "TUI should emit OSC 7 when its working directory changes", "text": "### What variant of Codex are you using? CLI ### What feature would you like to see? When you resume a session in a different working directory, Codex needs to tell the terminal emulator which directory it is using. OSC 7 is the standard way to do that. This is supported by modern Linux/macOS terminals and by Windows Terminal following https://github.com/microsoft/terminal/pull/20019 I don't know what other behaviours in codex may need this other than resume, there may be some. ### Additional information In my case, I want this so Ctrl+Shift+T opens the same working directory as codex is using. I'm using ghostty", "url": "https://github.com/openai/codex/issues/38229", "createdAt": "2026-08-12T18:05:07Z", "updatedAt": "2026-08-12T18:05:48Z", "timestamp": "2026-08-12T18:05:48Z", "metrics": { "reactions": 0, "comments": 0 }, "labels": [ "enhancement", "TUI", "CLI" ], "author": "JeremyMoeglich", "state": "open", "assignees": [] }, { "id": "github:openai/codex:issue:38230", "source": "github", "group": "coding-agent-infrastructure", "project": "openai/codex", "kind": "issue", "title": "MCP tool calls crash with aws-lc-rs jitter-entropy panic (\"Transport closed\") once they run past ~90 seconds — not specific to fan-out calls", "text": "**UPDATE 3 (recovery timing is inconsistent, not a fixed window):** The first update above described the poisoned window as temporary, self-clearing in roughly 30-75 minutes without a restart. A dedicated follow-up test running the full 90-minute poll (single MCP call every 5 minutes, no restart, same process the whole time) never recovered: **18/18 attempts over 1h 29m 19.5s all failed** with the identical signature. So across the two runs observed: - Run 1: poisoned window lasted roughly 30-75 minutes, then cleared on its own. - Run 2: poisoned window lasted at least 89 minutes with zero recovery (test ended before it cleared, if it ever did). Conclusion: self-recovery is real (it has happened) but **not reliable or time-bounded** — don't rely on \"just wait\" as a fix. A full Codex process restart remains the only dependable way to clear the bad state; waiting can cost anywhere from nothing to well over 90 minutes with no guarantee of resolution. **UPDATE 2 (further correction, minimal repro found):** The previous update above framed this as correlating with multi-provider fan-out tool calls specifically. A controlled follow-up test shows that framing was still not quite right — please read this update as superseding it. Ran a set of isolated, single-purpose Codex CLI processes (`codex exec`), each making exactly **one** MCP tool call to a **single-provider** tool (no fan-out, no concurrency, one upstream model request per call), varying only how long the call took: | Test | Tool shape | Elapsed | Result | |---|---|---|---| | A | single-provider chat, moderate prompt | 61.7s | succeeded | | B | single-provider chat, deliberately large prompt/output | **106.9s** | **failed — `Transport closed` / `aws_lc_0_39_0_jent_entropy_switch_notime_impl`, identical to every prior occurrence** | Test B made no other MCP or fan-out calls whatsoever. This is the smallest reproduction so far: **a single MCP tool call, to a single provider, with no concurrency of any kind, crashes the same way once it runs past roughly 90-100 seconds.** Combined with the earlier data, the actual pattern appears to be: - Any individual MCP tool call that completes in well under ~90s succeeds reliably (observed up to 61.7s). - Any individual MCP tool call that runs past ~90-107s crashes with this exact signature, regardless of whether it's a single-provider call or a multi-provider fan-out call. - Multi-provider fan-out calls aren't special in themselves — they just reliably run long enough (waiting on the slowest of N concurrent upstream requests) to cross whatever this threshold is, so they appeared correlated with the crash in earlier testing. A single slow call crosses the same threshold and crashes identically. This points strongly at a **fixed internal timeout somewhere around 90 seconds in Codex's own MCP client/tool-call path**, whose expiry handling exercises aws-lc-rs's Jitter Entropy self-test, and that self-test failing takes down the shared MCP transport (see prior update for the temporary-not-permanent poisoned-window behavior) rather than just cleanly failing the one slow call. If it's useful for tracking down the actual timeout constant: the four measured failure durations across this whole investigation were 91.77s, 92.33s, 92.88s, and 106.86s — consistent with a timeout in the ~90s neighborhood plus some retry/overhead variance, not a hard single fixed value observed so far. **UPDATE (correction):** The original report below claimed this crash permanently disables MCP tool calls for the rest of the session, with the only fix being a full process restart. Further log analysis shows that claim was wrong in an important way, and I want to correct it rather than leave inaccurate info in the issue. Corrected understanding: - The crash consistently occurs on tool calls that internally **fan out to multiple upstream model providers concurrently** (a \"council\"-style tool issuing several parallel requests), and consistently after **~90-93 seconds** of the call being in flight. Three independent occurrences in one session measured 92.33s, 92.88s, and 91.77s before failing — suspiciously close to a fixed internal timeout, not random jitter. - **Single-provider tool calls on the same MCP server never triggered the crash directly**, even when they ran just as long (up to 45s observed) or were issued minutes before/after a fan-out crash. - After a crash, there IS a window where all subsequent MCP tool calls — including calls to a *different*, unrelated stdio MCP server — fail instantly with the identical error. But this window is **temporary, not permanent**: in the session analyzed, it lasted roughly 30-75 minutes and then cleared on its own, with a call to the same server succeeding again with no process restart. A second and third fan-out call later re-triggered fresh ~90s-duration crashes, each followed by another temporary all-calls-fail window. Revised timeline from one session (tool/server names generalized; \"Server 1\" = a custom stdio MCP server proxying an internal model gateway, \"Server 2\" = a second, unrelated custom stdio MCP server; \"fan-out tool\" = a tool that issues several concurrent upstream requests per call, \"chat tool\" = a tool that issues one upstream request per call): ``` t+0:00 Server 1 / list-models tool completed 0.27s t+0:47 Server 1 / fan-out tool completed 24.28s ...(~10h gap)... t+10:11 Server 1 / list-models tool completed 0.14s t+10:13 Server 2 / fan-out tool FAILED 92.33s <- crash #1 t+10:13 Server 1 / chat tool completed 21.85s <- recovers immediately t+10:14 Server 1 / chat tool completed 28.03s t+10:14 Server 1 / chat tool completed 19.66s t+10:15 Server 1 / chat tool completed 8.49s t+10:15 Server 1 / chat tool completed 6.66s t+10:15 Server 1 / chat tool completed 8.43s t+10:16 Server 1 / chat tool completed 39.30s t+10:16 Server 1 / chat tool completed 2.88s t+10:34 Server 1 / fan-out tool completed 31.14s t+10:34 Server 1 / fan-out tool completed 31.73s t+10:35 Server 1 / fan-out tool completed 27.15s t+10:53 Server 1 / fan-out tool completed 30.51s t+11:35 Server 1 / fan-out tool FAILED 92.88s <- crash #2 t+11:35 Server 1 / fan-out tool FAILED 0.00s (instant, poisoned window) t+11:35 Server 2 / fan-out tool FAILED 0.00s t+11:35 Server 1 / chat tool FAILED 0.00s t+12:06 Server 1 / list-models tool FAILED 0.00s t+12:47 Server 1 / chat tool completed 45.26s <- recovers again, unprompted t+12:49 Server 1 / fan-out tool FAILED 91.77s <- crash #3 t+12:49 Server 1 / chat tool FAILED 0.00s ``` So the more accurate framing is: **a concurrent multi-provider MCP tool call reliably crashes Codex's MCP transport after ~90 seconds**, which then produces a temporary (not permanent) window where all MCP calls across all configured servers fail instantly, before self-clearing. A full Codex restart is still a reliable way to clear the bad state immediately, but it isn't the only way it clears, and the failure isn't scoped to \"the rest of the session\" as originally stated. I'd guess the ~90s constant points at some fixed internal timeout (tokio timeout, keepalive, or reconnect-attempt deadline) whose expiry path exercises aws-lc-rs's Jitter Entropy self-test, and that self-test failing takes down more than the one in-flight request. The multi-provider fan-out correlation suggests the trigger may specifically involve concurrent connection/TLS-session-ticket handling rather than any long-running call in general — that's the piece I'd focus investigation on given this data. --- ## Original report ## Title MCP tool calls permanently fail with \"Transport closed\" (aws-lc-rs jitter-entropy panic) for the rest of the session after one crash ## Codex CLI version 0.147.0 (npm install, `@openai/codex`) ## Environment - OS: Windows 11 Enterprise (build 10.0.26200), x86_64 - Install method: npm global install - `model_provider` uses a custom OpenAI-compatible endpoint with `wire_api = \"responses\"` - Multiple `mcp_servers` entries configured as local stdio servers (each spawns a local Python subprocess) - Tested with `[windows] sandbox = \"elevated\"` and also with `--dangerously-bypass-approvals-and-sandbox` (sandboxing fully disabled) — see notes below ## What happened During a long-running interactive session, an MCP tool call to one configured stdio MCP server failed with: ``` tool call error: tool call failed for `/` Caused by: Transport closed Stack backtrace: 0: 1: 2: aws_lc_0_39_0_jent_entropy_switch_notime_impl 3: 4: 5: 6: 7: 8: 9: 10: 11: 12: 13: 14: 15: 16: 17: 18: 19: 20: 21: 22: 23: BaseThreadInitThunk 24: RtlUserThreadStart ``` After this first failure, **every subsequent MCP tool call for the remainder of the session** — including calls to a completely different, unrelated MCP server — failed instantly (single-digit milliseconds, versus the ~90 seconds the original call had been in flight) with the byte-for-byte identical error. This persisted across dozens of tool calls and roughly 20 hours of wall-clock time until the Codex process was manually killed and a new session started, after which MCP tool calls worked normally again. ## Diagnosis notes - The tool call that first crashed was **not** the one that failed on every later attempt — the failure is not scoped to one server or one tool. Once it happens, calls to any configured MCP server instantly fail identically. - Confirmed the MCP servers themselves stayed healthy the whole time: calling the same underlying tools directly via a separate, non-Codex MCP client succeeded normally while the Codex session was still reporting `Transport closed` for every attempt. - Reproduced the healthy path in a fresh Codex process (`codex exec --dangerously-bypass-approvals-and-sandbox`) immediately after killing the poisoned process — same MCP server, same tool, clean result. This isolates the fault to Codex's own process state, not the server or config. - Correlated the poisoned session's PID to its exact launch flags via `Get-CimInstance Win32_Process`: it was started with `--dangerously-bypass-approvals-and-sandbox`, i.e. **sandboxing was already fully disabled** when the crash occurred. So Windows sandbox mode (`elevated` vs `unelevated`) does not appear to be a causal factor, at least not exclusively. - The stack symbol `aws_lc_0_39_0_jent_entropy_switch_notime_impl` points at aws-lc-rs's Jitter Entropy health-test/self-test path, which is designed to abort hard on failure. Whatever thread/task that runs in appears to share fate with (or block) the MCP connection multiplexer for the entire process, since a single failure there poisons all subsequent MCP calls rather than just the one in flight. ## Impact - A single transient crash (plausibly triggered by host timer-precision conditions — e.g. corporate endpoint-security software hooking high-resolution timer APIs, virtualization, etc.) takes down MCP tool access for the rest of the session, silently, with no recovery path short of fully restarting Codex. - There's no user-facing signal that this is a fatal, permanent, process-wide failure rather than a transient per-call error. The identical error repeats on every retry, which reads like a flaky single tool/server rather than \"the process's MCP subsystem is dead.\" ## Expected behavior - Ideally the aws-lc-rs entropy self-test failure shouldn't crash any part of the process — or if it must, it should only fail the one in-flight request rather than permanently poisoning the shared MCP transport. - Short of a fix, it would help if Codex detected a dead/corrupted MCP transport and attempted to reconnect/respawn per-server on the next call, or at minimum surfaced a distinct error (\"MCP subsystem has crashed — restart Codex\") instead of repeating the same per-call error indefinitely. ## Suggested investigation - Why does a Jitter Entropy self-test failure (which reads as a local CPU/timing health check, unrelated to any actual network TLS handshake for a local stdio MCP server) get exercised on the MCP tool-call path at all? - Why does one failure there cascade to every other configured MCP server, rather than being isolated to the connection that hit it?", "url": "https://github.com/openai/codex/issues/38230", "createdAt": "2026-08-12T18:05:39Z", "updatedAt": "2026-08-12T20:00:49Z", "timestamp": "2026-08-12T20:00:49Z", "metrics": { "reactions": 0, "comments": 3 }, "labels": [ "bug", "windows-os", "mcp", "CLI", "connectivity" ], "author": "ravindren-sm", "state": "open", "assignees": [] }, { "id": "github:openai/codex:issue:38231", "source": "github", "group": "coding-agent-infrastructure", "project": "openai/codex", "kind": "issue", "title": "This task is active elsewhere. Close it there, then retry here.", "text": "### What version of the IDE extension are you using? 26.803.61601 ### What subscription do you have? Plus ### Which IDE are you using? VS code ### What platform is your computer? _No response_ ### What issue are you seeing? It tells me: This is open in another app Close it there to continue here. But this is not the case at all. I had it running in vscode > codex plugin, closed vscode, and reopened again. ### What steps can reproduce the bug? Simply open VScode, and select a chat. ### What is the expected behavior? _No response_ ### Additional information _No response_", "url": "https://github.com/openai/codex/issues/38231", "createdAt": "2026-08-12T18:10:24Z", "updatedAt": "2026-08-12T18:11:48Z", "timestamp": "2026-08-12T18:11:48Z", "metrics": { "reactions": 0, "comments": 1 }, "labels": [ "bug", "extension", "session" ], "author": "AndySharez", "state": "open", "assignees": [] }, { "id": "github:openai/codex:issue:38233", "source": "github", "group": "coding-agent-infrastructure", "project": "openai/codex", "kind": "issue", "title": "GPT-5.6 Sol normal mode appears to consume Codex quota unusually fast on $100 plan", "text": "### What subscription do you have? $100/month ChatGPT plan. ### Which model were you using? GPT-5.6 Sol. Fast Mode is explicitly **disabled**. This report is about normal mode. ### What platform is your computer? Windows 11 Pro x64. ### What issue are you seeing? Over roughly the last 2–3 days (around August 10–12, 2026), Codex in normal mode has appeared noticeably faster than before, while the included usage/quota is also depleting much faster than expected for comparable ordinary development work. I have not enabled Fast Mode, so the documented Fast Mode credit multiplier should not explain this behavior. The abrupt change makes this look like a possible regression in one of the following areas: - token/context usage; - cached-input accounting; - quota/credit calculation; - automatically injected context, plugins, skills, memory, or tool schemas; - or server-side entitlement/rate-limit accounting. There are other current reports describing unusually fast usage depletion, including #38191, so this may not be isolated to one account. Please investigate whether normal-mode GPT-5.6 Sol usage accounting changed or regressed during the August 10–12 rollout window. It would also be very useful to expose a per-thread breakdown of input tokens, cached input tokens, output/reasoning tokens, and the corresponding quota/credit charge so users can distinguish genuine model consumption from an accounting problem. ### What steps can reproduce the bug? 1. Use Codex on Windows with GPT-5.6 Sol. 2. Confirm Fast Mode is OFF. 3. Perform normal coding tasks similar to tasks used on previous days. 4. Compare the Codex usage/quota meter before and after the tasks. 5. Observe that the available usage appears to drop materially faster than it did before approximately August 10, despite Fast Mode remaining disabled. ### What is the expected behavior? Normal mode should consume usage according to the documented normal-mode token/credit rates. An abrupt increase in depletion should either be documented as an intentional pricing/accounting change or investigated as a regression. If the backend is correctly charging the usage, the product should provide enough per-thread token and credit detail to explain the difference. ### Additional information I am intentionally not posting account identifiers or private project/session data publicly. Exact session IDs and account-specific usage details can be provided through a private OpenAI support channel if needed.", "url": "https://github.com/openai/codex/issues/38233", "createdAt": "2026-08-12T18:22:22Z", "updatedAt": "2026-08-13T10:26:35Z", "timestamp": "2026-08-13T10:26:35Z", "metrics": { "reactions": 0, "comments": 2 }, "labels": [ "bug", "windows-os", "rate-limits" ], "author": "McFly8819", "state": "open", "assignees": [] }, { "id": "github:openai/codex:issue:38234", "source": "github", "group": "coding-agent-infrastructure", "project": "openai/codex", "kind": "issue", "title": "Dropped app-server events corrupt resumed Codex sessions", "text": "### What version of Codex CLI is running? codex-cli 0.147.0 ### What subscription do you have? $20/mo ### Which model were you using? gpt-5.6-sol ### What platform is your computer? Darwin 25.0.0 arm64 arm ### What terminal emulator and version are you using (if applicable)? Ghostty 1.2.0; no multiplexer ### Codex doctor report ```json { \"schemaVersion\": 1, \"generatedAt\": \"1786558899s since unix epoch\", \"overallStatus\": \"ok\", \"codexVersion\": \"0.147.0\", \"checks\": { \"app_server.status\": { \"id\": \"app_server.status\", \"category\": \"app-server\", \"status\": \"ok\", \"summary\": \"background server is not running\", \"details\": { \"control socket\": \"/Users/REDACTED/.codex/app-server-control/app-server-control.sock\", \"daemon state dir\": \"/Users/REDACTED/.codex/app-server-daemon\", \"mode\": \"ephemeral\", \"pid file\": \"/Users/REDACTED/.codex/app-server-daemon/app-server.pid (missing)\", \"settings\": \"/Users/REDACTED/.codex/app-server-daemon/settings.json (missing)\", \"status\": \"not running\", \"update-loop pid file\": \"/Users/REDACTED/.codex/app-server-daemon/app-server-updater.pid (missing)\" }, \"remediation\": null, \"durationMs\": 6 }, \"auth.credentials\": { \"id\": \"auth.credentials\", \"category\": \"auth\", \"status\": \"ok\", \"summary\": \"auth is configured\", \"details\": { \"auth file\": \"/Users/REDACTED/.codex/auth.json\", \"auth storage mode\": \"File\", \"stored API key\": \"false\", \"stored ChatGPT tokens\": \"true\", \"stored agent identity\": \"false\", \"stored auth mode\": \"chatgpt\" }, \"remediation\": null, \"durationMs\": 0 }, \"config.load\": { \"id\": \"config.load\", \"category\": \"config\", \"status\": \"ok\", \"summary\": \"config loaded\", \"details\": { \"CODEX_HOME\": \"/Users/REDACTED/.codex\", \"config.toml\": \"/Users/REDACTED/.codex/config.toml\", \"config.toml parse\": \"ok\", \"cwd\": \"/Users/REDACTED/mystuff/Coding/cascade-browser\", \"enabled feature flags\": \"shell_tool, view_image, unified_exec, shell_snapshot, code_mode_host, terminal_resize_reflow, sqlite, hooks, enable_request_compression, multi_agent, apps, tool_search_always_defer_mcp_tools, tool_suggest, plugins, in_app_browser, in_app_updates, browser_use, browser_use_full_cdp_access, browser_use_external, computer_use, remote_plugin, plugin_sharing, image_generation, resize_all_images, item_ids, skill_mcp_dependency_install, skill_search, mentions_v2, steer, guardian_approval, goals, collaboration_modes, tool_call_mcp_elicitation, auth_elicitation, personality, fast_mode, tui_app_server, remote_compaction_v2, workspace_dependencies\", \"feature flag overrides\": \"none\", \"feature flags enabled\": \"39\", \"log dir\": \"/Users/REDACTED/.codex/log\", \"mcp servers\": \"2\", \"model\": \"gpt-5.6-luna\", \"model provider\": \"openai\", \"sqlite home\": \"/Users/REDACTED/.codex\" }, \"remediation\": null, \"durationMs\": 1 }, \"git.environment\": { \"id\": \"git.environment\", \"category\": \"git\", \"status\": \"ok\", \"summary\": \"git version 2.50.1 (Apple Git-155)\", \"details\": { \".git entry\": \"directory\", \"PATH git #1\": \"/usr/bin/git\", \"PATH git entries\": \"1\", \"git branch\": \"master\", \"git build options\": \"git version 2.50.1 (Apple Git-155); cpu: arm64; no commit associated with this build; sizeof-long: 8; sizeof-size_t: 8; shell-path: /bin/sh; feature: fsmonitor--daemon; libcurl: 8.7.1; zlib: 1.2.12; SHA-1: SHA1_DC; SHA-256: SHA256_BLK\", \"git exec path\": \"/Applications/Xcode.app/Contents/Developer/usr/libexec/git-core\", \"git version\": \"git version 2.50.1 (Apple Git-155)\", \"repo detected\": \"true\", \"repo root\": \"/Users/REDACTED/mystuff/Coding/cascade-browser\", \"selected git\": \"/usr/bin/git\" }, \"remediation\": null, \"durationMs\": 1515 }, \"installation\": { \"id\": \"installation\", \"category\": \"install\", \"status\": \"ok\", \"summary\": \"installation looks consistent\", \"details\": { \"PATH codex #1\": \"/opt/homebrew/bin/codex\", \"current executable\": \"/opt/homebrew/lib/node_modules/@openai/codex/node_modules/@openai/codex-darwin-arm64/vendor/aarch64-apple-darwin/bin/codex\", \"install context\": \"npm (package /opt/homebrew/lib/node_modules/@openai/codex/node_modules/@openai/codex-darwin-arm64/vendor/aarch64-apple-darwin, bin /opt/homebrew/lib/node_modules/@openai/codex/node_modules/@openai/codex-darwin-arm64/vendor/aarch64-apple-darwin/bin, resources /opt/homebrew/lib/node_modules/@openai/codex/node_modules/@openai/codex-darwin-arm64/vendor/aarch64-apple-darwin/codex-resources, path /opt/homebrew/lib/node_modules/@openai/codex/node_modules/@openai/codex-darwin-arm64/vendor/aarch64-apple-darwin/codex-path)\", \"managed by bun\": \"false\", \"managed by npm\": \"true\", \"managed by pnpm\": \"false\", \"managed package root\": \"/opt/homebrew/lib/node_modules/@openai/codex\", \"npm update target\": \"/opt/homebrew/lib/node_modules/@openai/codex\" }, \"remediation\": null, \"durationMs\": 1738 }, \"mcp.config\": { \"id\": \"mcp.config\", \"category\": \"mcp\", \"status\": \"ok\", \"summary\": \"MCP configuration is locally consistent\", \"details\": { \"configured servers\": \"2\", \"disabled servers\": \"1\", \"stdio servers\": \"2\" }, \"remediation\": null, \"durationMs\": 0 }, \"network.env\": { \"id\": \"network.env\", \"category\": \"network\", \"status\": \"ok\", \"summary\": \"network-related environment looks readable\", \"details\": { \"proxy env vars\": \"none\" }, \"remediation\": null, \"durationMs\": 0 }, \"network.provider_reachability\": { \"id\": \"network.provider_reachability\", \"category\": \"reachability\", \"status\": \"ok\", \"summary\": \"active provider endpoints are reachable over HTTP\", \"details\": { \"ChatGPT base URL\": \"https://chatgpt.com/backend-api/ reachable (HTTP 403)\", \"reachability mode\": \"ChatGPT auth\" }, \"remediation\": null, \"durationMs\": 1733 }, \"network.websocket_reachability\": { \"id\": \"network.websocket_reachability\", \"category\": \"websocket\", \"status\": \"ok\", \"summary\": \"Responses WebSocket handshake succeeded\", \"details\": { \"DNS\": \"2 IPv4, 0 IPv6, first IPv4\", \"auth mode\": \"chatgpt\", \"connect timeout\": \"15000 ms\", \"endpoint\": \"wss://chatgpt.com/backend-api/\", \"handshake result\": \"HTTP 101 Switching Protocols\", \"model provider\": \"openai\", \"models etag present\": \"true\", \"provider name\": \"OpenAI\", \"proxy env vars\": \"none\", \"reasoning header\": \"false\", \"server model present\": \"false\", \"supports websockets\": \"true\", \"wire API\": \"responses\" }, \"remediation\": null, \"durationMs\": 2412 }, \"runtime.provenance\": { \"id\": \"runtime.provenance\", \"category\": \"runtime\", \"status\": \"ok\", \"summary\": \"running npm on macos-aarch64\", \"details\": { \"commit\": \"unknown\", \"current executable\": \"/opt/homebrew/lib/node_modules/@openai/codex/node_modules/@openai/codex-darwin-arm64/vendor/aarch64-apple-darwin/bin/codex\", \"install method\": \"npm (package /opt/homebrew/lib/node_modules/@openai/codex/node_modules/@openai/codex-darwin-arm64/vendor/aarch64-apple-darwin, bin /opt/homebrew/lib/node_modules/@openai/codex/node_modules/@openai/codex-darwin-arm64/vendor/aarch64-apple-darwin/bin, resources /opt/homebrew/lib/node_modules/@openai/codex/node_modules/@openai/codex-darwin-arm64/vendor/aarch64-apple-darwin/codex-resources, path /opt/homebrew/lib/node_modules/@openai/codex/node_modules/@openai/codex-darwin-arm64/vendor/aarch64-apple-darwin/codex-path)\", \"platform\": \"macos-aarch64\", \"version\": \"0.147.0\" }, \"remediation\": null, \"durationMs\": 0 }, \"runtime.search\": { \"id\": \"runtime.search\", \"category\": \"search\", \"status\": \"ok\", \"summary\": \"search is OK (bundled)\", \"details\": { \"search command\": \"/opt/homebrew/lib/node_modules/@openai/codex/node_modules/@openai/codex-darwin-arm64/vendor/aarch64-apple-darwin/codex-path/rg\", \"search command readiness\": \"file exists\", \"search provider\": \"bundled\" }, \"remediation\": null, \"durationMs\": 17 }, \"sandbox.helpers\": { \"id\": \"sandbox.helpers\", \"category\": \"sandbox\", \"status\": \"ok\", \"summary\": \"sandbox configuration is readable\", \"details\": { \"approval policy\": \"OnRequest\", \"codex-linux-sandbox helper\": \"none\", \"execve wrapper helper\": \"/Users/REDACTED/.codex/tmp/arg0/codex-arg0msOPmE/codex-execve-wrapper\", \"filesystem sandbox\": \"restricted\", \"network sandbox\": \"restricted\" }, \"remediation\": null, \"durationMs\": 0 }, \"state.paths\": { \"id\": \"state.paths\", \"category\": \"state\", \"status\": \"ok\", \"summary\": \"state paths and databases are inspectable\", \"details\": { \"CODEX_HOME\": \"/Users/REDACTED/.codex (dir)\", \"active rollout files\": \"128 files, 211775217 total bytes, 1654493 average bytes\", \"archived rollout files\": \"0 files, 0 total bytes, 0 average bytes\", \"goals DB\": \"/Users/REDACTED/.codex/goals_1.sqlite (file)\", \"goals DB integrity\": \"ok\", \"log DB\": \"/Users/REDACTED/.codex/logs_2.sqlite (file)\", \"log DB integrity\": \"ok\", \"log dir\": \"/Users/REDACTED/.codex/log (dir)\", \"memories DB\": \"/Users/REDACTED/.codex/memories_1.sqlite (file)\", \"memories DB integrity\": \"ok\", \"queue DB\": \"/Users/REDACTED/.codex/queue_1.sqlite (file)\", \"queue DB integrity\": \"ok\", \"sqlite home\": \"/Users/REDACTED/.codex (dir)\", \"state DB\": \"/Users/REDACTED/.codex/state_5.sqlite (file)\", \"state DB integrity\": \"ok\", \"thread history DB\": \"/Users/REDACTED/.codex/thread_history_1.sqlite (file)\", \"thread history DB integrity\": \"ok\" }, \"remediation\": null, \"durationMs\": 3540 }, \"state.rollout_db_parity\": { \"id\": \"state.rollout_db_parity\", \"category\": \"threads\", \"status\": \"ok\", \"summary\": \"rollout files and state DB thread inventory agree\", \"details\": { \"default model provider\": \"openai\", \"rollout DB active files\": \"128\", \"rollout DB active rows\": \"128\", \"rollout DB archive mismatches\": \"0\", \"rollout DB archived files\": \"0\", \"rollout DB archived rows\": \"0\", \"rollout DB duplicate DB paths\": \"0\", \"rollout DB duplicate rollout thread ids\": \"0\", \"rollout DB malformed file names\": \"0\", \"rollout DB missing active rows\": \"0\", \"rollout DB missing archived rows\": \"0\", \"rollout DB model providers\": \"openai=128\", \"rollout DB rows\": \"128\", \"rollout DB scan cap reached\": \"false\", \"rollout DB scan errors\": \"0\", \"rollout DB sources\": \"exec=47, subagent:thread_spawn=39, cli=18, vscode=17, subagent:other=7\", \"rollout DB stale rows\": \"0\" }, \"remediation\": null, \"durationMs\": 2253 }, \"system.environment\": { \"id\": \"system.environment\", \"category\": \"system\", \"status\": \"ok\", \"summary\": \"OS language en-US\", \"details\": { \"EDITOR\": \"set\", \"GH_PAGER\": \"set\", \"GIT_PAGER\": \"set\", \"LANG\": \"C.UTF-8\", \"LC_ALL\": \"C.UTF-8\", \"LC_CTYPE\": \"C.UTF-8\", \"PAGER\": \"set\", \"VISUAL\": \"not set\", \"os\": \"Mac OS 26.0.1 [64-bit]\", \"os language\": \"en-US\", \"os type\": \"Mac OS\", \"os version\": \"26.0.1\" }, \"remediation\": null, \"durationMs\": 127 }, \"terminal.env\": { \"id\": \"terminal.env\", \"category\": \"terminal\", \"status\": \"ok\", \"summary\": \"terminal metadata was detected\", \"details\": { \"COLORTERM\": \"present\", \"NO_COLOR\": \"1\", \"TERMINFO\": \"/Applications/Ghostty.app/Contents/Resources/terminfo (dir)\", \"TERM_PROGRAM\": \"ghostty\", \"color output\": \"disabled (NO_COLOR)\", \"effective locale\": \"C.UTF-8\", \"stderr is terminal\": \"false\", \"stdin is terminal\": \"false\", \"stdout is terminal\": \"false\", \"terminal\": \"Ghostty\", \"terminal size\": \"80x24\", \"terminal version\": \"1.2.0\" }, \"remediation\": null, \"durationMs\": 70 }, \"terminal.title\": { \"id\": \"terminal.title\", \"category\": \"title\", \"status\": \"ok\", \"summary\": \"terminal title default\", \"details\": { \"terminal title activity\": \"true\", \"terminal title items\": \"activity, project-name\", \"terminal title project source\": \"git repo root\", \"terminal title project value\": \"cascade-browser\", \"terminal title source\": \"default\" }, \"remediation\": null, \"durationMs\": 1 }, \"updates.status\": { \"id\": \"updates.status\", \"category\": \"updates\", \"status\": \"ok\", \"summary\": \"update configuration is locally consistent\", \"details\": { \"cached latest version\": \"0.147.0\", \"check for update on startup\": \"true\", \"last checked at\": \"2026-08-12T00:12:12.876114Z\", \"latest version\": \"0.147.0\", \"latest version status\": \"current version is not older\", \"npm update target\": \"/opt/homebrew/lib/node_modules/@openai/codex\", \"update action\": \"npm install -g @openai/codex\", \"version cache\": \"/Users/REDACTED/.codex/version.json\" }, \"remediation\": null, \"durationMs\": 1731 } } } ``` ### What issue are you seeing? A long-running `codex exec resume --json` session emitted repeated app-server lag errors and dropped hundreds of events. Later attempts to resume the same session could not continue because a custom tool-call result was missing. The process stayed alive and repeatedly printed the same error without producing a response. ### What steps can reproduce the bug? 1. Start or resume a Codex session through `codex exec resume --json`. 2. Let the session perform a long-running workflow with repeated tool calls and polling. 3. Allow the in-process app-server event consumer to fall behind. 4. Observe event-drop errors. 5. Resume the same Codex session with another prompt. ### What is the expected behavior? ## Expected behavior Event-stream backpressure should not permanently corrupt session state. If events must be dropped, Codex should preserve required tool-call/result pairs, recover the missing state, or terminate the turn with a clear retryable error. A resumed session should not wait indefinitely for an output that can never arrive. ### Additional information ## Actual behavior The original run emitted many errors in this form: ```text in-process app-server event stream lagged; dropped 43 events in-process app-server event stream lagged; dropped 171 events in-process app-server event stream lagged; dropped 854 events ``` Afterward, every resumed run repeatedly emitted: ```text ERROR codex_core::util: Custom tool call output is missing for call id: call_lgAAyVMavptKZY5NFEwPIkAo ``` The resumed process produced no assistant response and remained stuck until canceled. Starting additional turns on that same session reproduced the missing-output error. ## Impact - The session becomes unusable across subsequent resumes. - The harness sees a live process but receives no meaningful assistant output. - User prompts queue behind or repeatedly re-enter the broken session. - Recovery currently requires abandoning or rotating the session rather than simply retrying the turn. ## Relevant timing - Event-drop burst began: 2026-08-12 17:58:29 UTC - First missing tool-output error after resume: 2026-08-12 17:59:53 UTC - Error continued across another resumed run through at least 2026-08-12 18:05:56 UTC", "url": "https://github.com/openai/codex/issues/38234", "createdAt": "2026-08-12T18:24:18Z", "updatedAt": "2026-08-13T15:16:11Z", "timestamp": "2026-08-13T15:16:11Z", "metrics": { "reactions": 0, "comments": 2 }, "labels": [ "bug", "exec", "CLI", "app-server" ], "author": "diegocabello", "state": "open", "assignees": [] }, { "id": "github:openai/codex:issue:38235", "source": "github", "group": "coding-agent-infrastructure", "project": "openai/codex", "kind": "issue", "title": "Guardian infrastructure failures still surface as high-risk denials after retries are exhausted", "text": "### What version of Codex CLI is running? The user-facing failure was observed on `codex-cli 0.142.5`. The same terminal-status defect remains in `main` at [`b1373b74`](https://github.com/openai/codex/commit/b1373b74a27d1d9b65074a873202683355cae772). ### What subscription do you have? Pro ### Which model were you using? `gpt-5.6-sol` This was the user-selected parent-session model at the recorded failures. The internal Guardian reviewer model was not exposed, so this field does not identify which reviewer model returned the capacity error. ### What platform is your computer? `Microsoft Windows NT 10.0.19045.0 x64` The affected status mapping is platform-independent. ### What terminal emulator and version are you using (if applicable)? Windows Terminal `1.24.11911.0` with PowerShell `7.6.4` (`Core`, x64). ### Codex doctor report Not included. The failure occurs after the parent session is running, inside the Guardian review lifecycle. The deterministic reproduction uses a mock provider response and does not depend on installation, authentication, terminal, MCP, or state-database health. ### What issue are you seeing? When automatic approval review fails before producing a risk assessment, Codex correctly keeps the requested action blocked, but reports the terminal result as though Guardian had made a substantive high-risk denial: ```text Automatic approval review denied (risk: high, authorization: unknown): Automatic approval review failed: Selected model is at capacity. Please try a different model. ``` This occurred repeatedly after the reviewer exhausted its attempts. The same misleading status was also observed when the remote review/compaction task failed. In both cases no Guardian assessment had classified the requested action as high risk. Bounded retries for transient reviewer failures were merged in #27062. The remaining defect is the terminal state after those retries are exhausted. Current `main` records that condition as `FailedClosed` internally, but then constructs a public `High` / `Unknown` / `Deny` assessment: - Internal `FailedClosed` followed by the synthetic public denial: https://github.com/openai/codex/blob/b1373b74a27d1d9b65074a873202683355cae772/codex-rs/core/src/guardian/review.rs#L542-L566 - Core status enum without `Failed`: https://github.com/openai/codex/blob/b1373b74a27d1d9b65074a873202683355cae772/codex-rs/protocol/src/approvals.rs#L111-L119 - App-server status enum without `Failed`: https://github.com/openai/codex/blob/b1373b74a27d1d9b65074a873202683355cae772/codex-rs/app-server-protocol/src/protocol/v2/item.rs#L447-L457 This report is not asking Codex to fail open. Blocking the action is correct when no assessment is available. The bug is representing an infrastructure or protocol failure as if an actual high-risk judgment occurred. ### What steps can reproduce the bug? Deterministic source-level reproduction: 1. Configure `approvals_reviewer = \"auto_review\"` and request a command or patch that requires approval. 2. Make each Guardian review attempt return a provider failure such as `server_is_overloaded` with `Selected model is at capacity`. 3. Let the existing bounded retry budget run out. 4. Observe a terminal Guardian assessment reported as `Denied`, with `risk=High` and `authorization=Unknown`, even though no assessment payload was produced. 5. Observe the blocked target item represented as declined rather than failed. A focused integration test can use the existing mock Responses server and assert both that the action never executes and that the terminal review status is `Failed` with no assessment fields. ### What is the expected behavior? - Keep the target action blocked (fail closed). - Emit a distinct terminal Guardian status such as `Failed`. - Omit `riskLevel` and `userAuthorization` because no assessment supplied either value. - Preserve the underlying provider, transport, runtime, prompt-construction, or parsing error in `rationale`. - Map the blocked target item to an execution failure, not a user or policy decline. - Keep analytics, replay, TUI, Desktop, and app-server lifecycle status consistent. ### Additional information This status design is prior work, not a new proposal from this report: - #27072 implemented a truthful `Failed` terminal status across core, protocol, app-server, replay, TUI, schemas, analytics, and tests, but was closed without being merged. - #27540 handled exhausted capacity failures as reviewer unavailability rather than denial, but was also closed without being merged. - #27062 merged bounded retries for transient reviewer failures; it does not fix the terminal public status after all retries fail. - #15341 reported an older instance of the same misleading user-facing status, but was closed after its particular upstream request failure was addressed. - #37392 reports a current parse-failure trigger involving malformed reviewer JSON. Validating or retrying malformed output is complementary; if all attempts fail, the terminal status still needs to represent that no policy assessment was produced. After a broader review of the earlier implementation work, this issue is being closed as a separate tracker. The corrected reproduction details and current-`main` source references are retained here as supporting evidence.", "url": "https://github.com/openai/codex/issues/38235", "createdAt": "2026-08-12T18:30:51Z", "updatedAt": "2026-08-13T05:34:30Z", "timestamp": "2026-08-13T05:34:30Z", "metrics": { "reactions": 0, "comments": 2 }, "labels": [ "bug", "windows-os", "CLI", "safety-check", "app-server" ], "author": "starriet9", "state": "closed", "assignees": [] }, { "id": "github:openai/codex:issue:38236", "source": "github", "group": "coding-agent-infrastructure", "project": "openai/codex", "kind": "issue", "title": "[TUI] /model in Plan mode updates Default globally and changes Medium to High", "text": "### What version of Codex CLI is running? `codex-cli 0.146.0` ### What platform are you using? Windows, Codex CLI TUI. ### What issue are you seeing? Changing the model with `/model` while Plan mode is active does not preserve separate Default- and Plan-mode settings. Starting state: - Default mode: `gpt-5.6-terra`, Medium - Plan mode entered with Shift+Tab After running `/model` in Plan mode and selecting `gpt-5.6-sol`, Medium, the resulting state is: - Default mode: `gpt-5.6-sol`, Medium - Plan mode: `gpt-5.6-sol`, High The requested Sol/Medium selection is applied to Default mode, while Plan mode retains or introduces a High reasoning override. This makes it impossible through the observed flow to configure Default as Terra/Medium and Plan as Sol/Medium. ### Steps to reproduce 1. Start a Codex CLI session in Default mode using `gpt-5.6-terra` with Medium reasoning. 2. Press Shift+Tab to enter Plan mode. 3. Run `/model` while Plan mode is active. 4. Select `gpt-5.6-sol` with Medium reasoning. 5. Cycle between Default and Plan modes and inspect the model/reasoning shown for each. ### Expected behavior Either: - the selection made while Plan mode is active is saved as the Plan-mode override, leaving Default mode at Terra/Medium; or - the UI clearly asks whether the selection applies to the Plan override or the global Default setting, and respects that choice. Expected final state for this reproduction: - Default mode: Terra/Medium - Plan mode: Sol/Medium ### Actual behavior - Default mode changes to Sol/Medium. - Plan mode becomes Sol/High. ### Additional context Related issue #14379 states that `/model` in Plan mode should offer an “Apply to Plan mode override” path. The behavior above suggests that the scope is ambiguous, the Plan override is not being saved, or a separate Plan reasoning override is unexpectedly replacing Medium with High.", "url": "https://github.com/openai/codex/issues/38236", "createdAt": "2026-08-12T18:35:04Z", "updatedAt": "2026-08-12T18:35:51Z", "timestamp": "2026-08-12T18:35:51Z", "metrics": { "reactions": 0, "comments": 0 }, "labels": [ "bug", "windows-os", "TUI", "CLI", "plan" ], "author": "rajagiriravi", "state": "open", "assignees": [] }, { "id": "github:openai/codex:issue:38237", "source": "github", "group": "coding-agent-infrastructure", "project": "openai/codex", "kind": "issue", "title": "Codex Desktop does not enforce subagent cap or delegation depth, then root-scoped controls cannot clean up the full tree", "text": "### What version of the Codex App are you using? Codex Desktop `26.803.61601` (build `6396`). ### What platform is your computer? macOS / Apple Silicon. ### Summary A long-running Desktop task accumulated 64 successful root-level `spawn_agent` calls over approximately two days. Some children also spawned children recursively, producing observed agent paths at least six levels deep. The task's explicit project instructions imposed both of these safety limits: - no more than 15 agents total in the task - delegation depth 1 only; workers must not spawn workers Those limits were not enforced by the runtime. Eventually the Desktop UI showed 94 active subagent entries and the computer became severely resource-constrained. The cleanup path then produced a second failure: the root-scoped agent listing reported only `/root`, so the assistant incorrectly concluded that all workers had stopped. The UI still showed 94 active entries. The retained parent record contains only 10 root-level `interrupt_agent` calls for 64 root-level spawn calls, and recursive descendants were not globally enumerable through the scoped control path. No raw transcript, encrypted task payloads, repository names, source, credentials, or private logs are attached to this public report. ### Sanitized evidence From the original parent rollout: ```text spawn_agent calls: 64 interrupt_agent calls: 10 list_agents calls: 38 wait_agent calls: 56 ``` The 64 spawn calls occurred between 2026-08-10 and 2026-08-12. They were not all issued in a single burst. Examples of recursively created paths visible in retained activity events: ```text /root/final_diff_review/asset_test_scan/tests_identity_scan/identity_claim_check/parity_review/home_identity_review /root/domain_cutover_map/edge_architecture_audit/redirect_source_audit/config_redirect_scan/cf_worker_scan/redirect_patterns ``` At the incident point: - Desktop UI showed 94 active agents - root-scoped listing reported only `/root` - the assistant announced successful cleanup based on that incomplete listing - the UI contradicted the control result - the machine was severely slowed / destabilized After restarting into a fresh Desktop task, an OS process audit found no remaining `codex exec` worker swarm. This suggests the 94-entry symptom may include stale registry/UI state, but it does not remove the earlier runtime-cap and recursive-delegation failure. ### Steps to reproduce 1. Start a long-running Desktop task with multi-agent enabled. 2. Give the task a textual safety limit, for example a total cap of 15 agents and depth 1. 3. Over multiple turns, allow the parent to call `spawn_agent` repeatedly. 4. Allow at least one child to attempt nested delegation. 5. Observe that the runtime continues accepting launches after the textual cap and beyond depth 1. 6. Accumulate enough agents that the Desktop list becomes large and the machine slows down. 7. From the root task, use the agent-listing and interrupt controls to stop all workers. 8. Observe that the root-scoped listing may show only `/root` while Desktop still displays many active child entries. ### Expected behavior - The runtime should enforce a configurable hard total-agent cap independent of model compliance. - The runtime should enforce maximum delegation depth. - A child marked as non-delegating should not receive or be able to invoke `spawn_agent`. - The control plane should expose a global, authoritative list for the task lineage. - “Stop all” should atomically enumerate and terminate every descendant, then reconcile UI and backend state. - The app should never allow an incomplete scoped listing to look like proof that global cleanup succeeded. - When limits are reached, additional spawn calls should fail with a clear error before resource exhaustion. ### Actual behavior - 64 root-level spawn calls were accepted over the task lifetime despite a 15-agent textual cap. - Recursive child paths reached at least six levels despite a depth-1 rule. - Desktop displayed 94 active entries and the Mac became unstable. - Root-scoped cleanup controls did not expose the full set. - A false successful-cleanup conclusion was possible because the listing and UI disagreed. ### Related issues - #19197 covers orphaned agents, incomplete cleanup, and frozen sessions. - #25179 covers stale Desktop subagent UI/cache entries. - #24668 covers UI degradation at 15 agents. - #16688 covered TUI freezing during large fan-out. This report adds a distinct safety/control-plane failure: runtime non-enforcement of total-agent and delegation-depth limits, plus the absence of an authoritative lineage-wide cleanup operation. ### Suggested fix 1. Enforce max total descendants and max depth server-side in the spawn handler. 2. Propagate a non-delegating capability to workers and omit/reject the spawn tool there. 3. Add an authoritative lineage identifier and global descendant query. 4. Add an idempotent “interrupt entire lineage” operation. 5. Reconcile the Desktop list from backend lifecycle state after cleanup and on app restart. 6. Surface a warning when UI count and control-plane count disagree.", "url": "https://github.com/openai/codex/issues/38237", "createdAt": "2026-08-12T18:55:12Z", "updatedAt": "2026-08-12T18:56:34Z", "timestamp": "2026-08-12T18:56:34Z", "metrics": { "reactions": 0, "comments": 1 }, "labels": [ "bug", "app", "subagent", "performance" ], "author": "jamiojala", "state": "open", "assignees": [] }, { "id": "github:openai/codex:issue:38240", "source": "github", "group": "coding-agent-infrastructure", "project": "openai/codex", "kind": "issue", "title": "Random compaction bug blocking session completely.", "text": "### What version of Codex CLI is running? codex-cli 0.128.0 ### What subscription do you have? Pro ### Which model were you using? gpt-5.5 medium ### What platform is your computer? CachyOS ### What terminal emulator and version are you using (if applicable)? bash - Konsole ### Codex doctor report ```json ■ Error running remote compact task: unexpected status 404 Not Found: {\"detail\":\"Not Found\"}, url: https://chatgpt.com/backend-api/codex/responses/compact, cf-ray: a2a1db60588c37cd-BKK, request id: 6a8baa3a- 11cd-45f7-a784-86a9de43e263 [tkb@TANELORN-CACHYOS SideraV7]$ codex doctor --json error: unexpected argument '--json' found tip: to pass '--json' as a value, use '-- --json' Usage: codex [OPTIONS] [PROMPT] codex [OPTIONS] [ARGS] For more information, try '--help'. [tkb@TANELORN-CACHYOS SideraV7]$ ``` ### What issue are you seeing? During compaction hit a status 404 error in codex. ### What steps can reproduce the bug? Uploaded thread: 019fe013-cc73-7780-a17f-7cc61998d68e ### What is the expected behavior? No error, keep working. ### Additional information _No response_", "url": "https://github.com/openai/codex/issues/38240", "createdAt": "2026-08-12T19:30:22Z", "updatedAt": "2026-08-13T13:27:59Z", "timestamp": "2026-08-13T13:27:59Z", "metrics": { "reactions": 0, "comments": 7 }, "labels": [ "bug", "CLI", "context", "connectivity" ], "author": "Sorbe1", "state": "open", "assignees": [] }, { "id": "github:openai/codex:issue:38246", "source": "github", "group": "coding-agent-infrastructure", "project": "openai/codex", "kind": "issue", "title": "Accessibility: desktop app does not announce response status updates to screen readers", "text": "### What issue are you seeing? When using the ChatGPT desktop app with a screen reader, across Chat, Work, and Codex conversations, important conversation status updates are not announced the way they are in the ChatGPT web experience. On the web, screen-reader users receive useful status feedback during the interaction, such as an initial working/thinking status after sending a prompt, tool activity when applicable, and an indication when the response is complete. That initial “thinking” message functions primarily as feedback that ChatGPT has started working, even when the model is not doing extended reasoning. In the desktop app, those updates are not exposed with equivalent screen-reader feedback. As a result, a screen-reader user may have to manually navigate through the conversation to determine whether ChatGPT has started working, whether a tool call is happening, or whether the response has finished. This is distinct from issues involving focus placement or navigation to the latest response. The problem here is the absence of non-visual status feedback for important conversation state changes. ### Steps to reproduce 1. Open the ChatGPT desktop app. 2. Enable a screen reader. 3. Open any Chat, Work, or Codex conversation. 4. Send any prompt. 5. Observe that the desktop app does not provide the same screen-reader status feedback as the web experience to indicate that ChatGPT has started working. 6. If the prompt uses tools, observe that tool activity is also not announced equivalently. 7. When the response finishes, observe that response completion is not announced equivalently either. ### Expected behavior The desktop app should expose concise, non-disruptive screen-reader status announcements equivalent to the ChatGPT web experience, including relevant states such as: - An initial working/thinking status indicating that ChatGPT has started processing the request - Tool calls or tool activity, when applicable - Response complete The exact wording does not need to be identical, and “thinking” should not be interpreted as necessarily indicating extended model reasoning; its important function here is to provide immediate non-visual feedback that the request is being processed. These announcements should use appropriate live/status semantics without forcibly moving keyboard or screen-reader focus, so users can keep their current reading position and choose when to navigate to the new response. ### Why this matters Visual indicators showing that ChatGPT has started working, is using a tool, or has finished responding are not independently perceivable to a screen-reader user unless equivalent programmatic status updates are exposed. Without those announcements, users have to repeatedly navigate through the conversation just to determine what state the interaction is in. Since ChatGPT on the web already provides this feedback, matching that behavior in the desktop app would make Chat, Work, and Codex much more predictable and efficient for screen-reader users. ### Additional context Related accessibility reports already describe problems with screen-reader focus/navigation and dynamic content in the desktop/Codex experience, but this issue specifically concerns missing status announcements across the ChatGPT desktop app.", "url": "https://github.com/openai/codex/issues/38246", "createdAt": "2026-08-12T20:48:24Z", "updatedAt": "2026-08-12T20:59:01Z", "timestamp": "2026-08-12T20:59:01Z", "metrics": { "reactions": 0, "comments": 0 }, "labels": [ "enhancement", "app" ], "author": "lprazdnik", "state": "open", "assignees": [] }, { "id": "github:openai/codex:issue:38247", "source": "github", "group": "coding-agent-infrastructure", "project": "openai/codex", "kind": "issue", "title": "[Linux Desktop 0.147.0] Completed v2 subagents retain full stdio MCP runtimes", "text": "## Environment - Codex Desktop on Linux - Bundled / local CLI: `codex-cli 0.147.0` - Platform: `Linux 6.8.0-137-generic x86_64` (Ubuntu 24.04) - Authentication: ChatGPT subscription - MCP configuration at the time of reproduction: 8 enabled stdio servers plus 4 Streamable HTTP servers - Long-lived Desktop `app-server` - Multi-agent v2 / `spawn_agent` workflows ## What issue are you seeing? Completed subagents can leave their entire stdio MCP runtime resident under the live Desktop `app-server`. The processes are not zombies and are not reparented to PID 1: every retained MCP launcher/server is still a direct descendant of the same healthy `app-server`. On one real workload, after a subagent-heavy task: - 15 instances each of `context7`, `github`, `gitee`, `playwright`, and `codex-security` remained. - The 15 start clusters aligned across unrelated servers, so the growth unit was one complete MCP stack, not one crashing third-party server. - A sixth stdio MCP was unusually expensive because of its own development logging, amplifying the Codex lifecycle bug but not causing the stack duplication. - System used memory grew to about 29 GiB; the Desktop cgroup accounted for about 23.9 GiB RSS. - Sending SIGTERM only to the stale MCP descendants reduced system used memory to about 11 GiB and the Desktop cgroup to about 5.4 GiB. The live task then recreated one healthy current stack, demonstrating that the old stacks were not required for the current task. Local logs correlate each new process batch with: ```text spawn_agent / followup_task -> thread_spawn -> session_init -> session_init.mcp_manager_init -> mcp.runtime.refresh -> start_server_task ``` This is related to #12491 and #17832, but the narrower failure mode here is **completed v2 subagents retaining live runtimes while their logical agent identity remains resumable**. It is not a request to mark the spawn edge closed, and it is not only the already-fixed manager-replacement leak from #18881. ## Steps to reproduce 1. Configure several global stdio MCP servers. 2. Start Codex Desktop and keep the same `app-server` alive. 3. Run a task that creates subagents with `spawn_agent`; let them finish normally. 4. Repeat across several tasks and/or use follow-up/resume flows. 5. After every child reports a terminal status, count the `app-server` descendants by MCP command. 6. Observe complete, timestamp-aligned MCP stacks remaining after the child work has completed and memory increasing monotonically. The problem becomes especially visible with a high-memory stdio server, but it also reproduces as equal instance counts across small, unrelated servers. ## Current-main code observation The current v2 residency path can unload `Completed`, `Errored`, or `Interrupted` threads, preserving their durable logical identity so they can be reloaded on later delivery. However, that unload path is currently driven by a later residency-slot reservation under capacity pressure. The completion watcher delivers the child result to the parent and returns without proactively releasing the now-idle resident thread/runtime. This can leave completed children holding stdio MCP processes indefinitely when no later spawn forces eviction. Across multiple Desktop tasks, those resident stacks accumulate under the same long-lived `app-server`. Recent lazy startup work reduces how many MCPs a child starts, but any MCP actually started by the child still needs an idle release path. ## Expected behavior After a v2 subagent reaches a terminal status, its result has been delivered, its active turn is cleared, and its mailbox is empty: 1. Its resident execution runtime (including stdio MCP children) should be unloaded within a bounded period. 2. Its logical agent id/path and open spawn edge should remain durable so `followup_task` / `send_input` can transparently reload it. 3. Active turns and pending mailbox input must never be unloaded. 4. Repeating completed subagent runs should return MCP process counts and RSS near the idle baseline instead of growing monotonically. A regression test should use a PID-recording stdio MCP fixture, verify that the process exits after terminal idle, then send a follow-up and verify that the same logical agent reloads and can start/use MCP again. ## Related issues / changes - #12491 — broad Desktop MCP child cleanup tracking; latest maintainer guidance asks distinct bugs to be filed separately - #17832 — Playwright stdio processes retained after subagents - #17574 — subagent MCP helper process trees - #30408 — closed/archived threads retaining MCP processes - #33700 — persisted subagent state / rehydration observations (logical edge lifetime is related but should not be conflated with runtime residency) - #18881 / #19753 — explicit manager/client shutdown fixes - #26632 and #26997 — durable v2 unload/reload behavior - #38217 — lazy startup of required cached MCP servers for subagents I am preparing a minimal patch with tests. I understand external contributions are invitation-only; if maintainers agree that proactively releasing terminal-idle v2 runtimes is the right layer, please explicitly invite the PR and I will open it against `main`.", "url": "https://github.com/openai/codex/issues/38247", "createdAt": "2026-08-12T21:04:25Z", "updatedAt": "2026-08-12T21:05:38Z", "timestamp": "2026-08-12T21:05:38Z", "metrics": { "reactions": 0, "comments": 1 }, "labels": [ "bug", "mcp", "app", "subagent", "app-server", "performance" ], "author": "qzhqzh", "state": "open", "assignees": [] }, { "id": "github:openai/codex:issue:38248", "source": "github", "group": "coding-agent-infrastructure", "project": "openai/codex", "kind": "issue", "title": "Error when trying to create a side thread", "text": "### What version of Codex CLI is running? codex-cli 0.147.0 ### What subscription do you have? Plus ### Which model were you using? gpt-5.6-luna ### What platform is your computer? Linux 7.1.5-101.fc43.x86_64 x86_64 ### What terminal emulator and version are you using (if applicable)? _No response_ ### Codex doctor report ```json ``` ### What issue are you seeing? When I tried to run `/side`, I got the following error: Failed to start side conversation: thread/fork failed during TUI bootstrap: thread/fork failed: failed to prepare paginated fork: thread-store internal error: thread history projection for 019feda7-ecd3-7bc3- 8ad7-2abd990775cd expected ordinal 4211, got 4210 (code -32603) \"Image\" ### What steps can reproduce the bug? Uploaded thread: 019feda7-ecd3-7bc3-8ad7-2abd990775cd ### What is the expected behavior? When calling `/side` should just open a side thread. ### Additional information _No response_", "url": "https://github.com/openai/codex/issues/38248", "createdAt": "2026-08-12T21:08:37Z", "updatedAt": "2026-08-13T14:45:05Z", "timestamp": "2026-08-13T14:45:05Z", "metrics": { "reactions": 0, "comments": 5 }, "labels": [ "bug", "TUI", "CLI", "session" ], "author": "rafaself", "state": "closed", "assignees": [] }, { "id": "github:openai/codex:issue:38249", "source": "github", "group": "coding-agent-infrastructure", "project": "openai/codex", "kind": "issue", "title": "GitHub connector: inconsistent repository parameter name causes misleading schema error", "text": "### What issue are you seeing? The GitHub connector exposes inconsistent names for the same repository identifier across sibling tools. For example, `fetch_issue_comments` requires `repo_full_name`, while many other GitHub tools (including `create_issue`) require `repository_full_name`. This makes a plausible model-generated call fail before reaching GitHub. The resulting validation error also includes a workspace-admin message, even though the failure is only an input-field mismatch: ```text Parameters failed connector schema validation: repo_full_name [required]: Missing required property (does not match constraints configured by your ChatGPT workspace admin. If the issue persists, instruct the user to contact their workspace admin.); repo_full_name [required]: Missing required property ``` ### What steps can reproduce the bug? Call the GitHub connector using the naming convention exposed by many sibling tools: ```json { \"repository_full_name\": \"OWNER/REPO\", \"issue_number\": 123 } ``` Tool: ```text codex_apps.github.fetch_issue_comments ``` The call fails schema validation because `repo_full_name` is required. Retry with: ```json { \"repo_full_name\": \"OWNER/REPO\", \"issue_number\": 123 } ``` The call succeeds. ### What is the expected behavior? Use one repository-field name consistently across GitHub connector tools, preferably `repository_full_name`, or accept both forms as compatibility aliases. For a plain schema mismatch, the error should identify the unexpected/missing field without suggesting workspace-admin intervention. ### Additional information Observed with the OpenAI GitHub plugin version `0.1.8-2841cf9749ae`. This is not an authentication, repository-access, or workspace-policy failure: changing only the parameter name makes the same read-only request succeed.", "url": "https://github.com/openai/codex/issues/38249", "createdAt": "2026-08-12T21:10:36Z", "updatedAt": "2026-08-12T21:11:17Z", "timestamp": "2026-08-12T21:11:17Z", "metrics": { "reactions": 0, "comments": 0 }, "labels": [ "bug", "tool-calls", "skills" ], "author": "bbk1ng", "state": "open", "assignees": [] }, { "id": "github:openai/codex:issue:38250", "source": "github", "group": "coding-agent-infrastructure", "project": "openai/codex", "kind": "issue", "title": "Codex Desktop can remain blank indefinitely when opening tasks with stale subagents", "text": "### What version of the Codex App are you using? Codex Desktop `26.803.61601` (build `6396`), bundled CLI `0.147.0-alpha.6.5`. ### What platform is your computer? macOS 26.5.2 (`25F84`), Apple silicon (`arm64`). ### What issue are you seeing? Some existing tasks never finish opening. Selecting an affected task leaves the conversation blank with a loading spinner for several minutes. Quitting and reopening the app does not resolve it, while other existing tasks load normally. This makes the affected work inaccessible. The app shows no error, retry option or indication of what it is waiting for. A local diagnostic check found: - The affected task's history is present and valid: about 1.3 MB, 331 JSONL records and one turn. - Direct app-server `thread/read` (including turns) and `thread/resume` calls both succeed, returning 331 items with zero parse errors. - The Desktop app repeatedly sends `thread/read` and `thread/resume` requests, but the renderer remains blank. - The affected parent task has three month-old child-agent edges still marked `open`. None has a writer lock, but the UI reports three subagents as `Working`. - In the same local database, 33 active parent tasks have 284 `open` child edges older than 24 hours; 256 are older than seven days. The stale child-agent state is a strong correlation, not a confirmed root cause. The backend can read and resume the parent task successfully, so this looks like a Desktop task-loading or state-rehydration problem rather than missing or malformed history. ### What steps can reproduce the bug? I do not yet have a minimal fresh-task reproducer, but the failure is repeatable for the affected task: 1. Open a long-running task that previously used subagents. 2. Quit and restart Codex Desktop. 3. Select the task. 4. The task remains blank with a loading spinner and does not render its history. Clearing disposable renderer caches and reconciling the active thread database with the available history files did not fix this task. A different existing task loaded successfully afterward. ### What is the expected behaviour? An existing task with valid local history should render promptly. Historical or stale child-agent records should not prevent the parent task from opening. If the app cannot complete task rehydration, it should show a bounded error with a retry or repair action rather than spin indefinitely. ### Related issues - #37041: historical subagents rehydrated as active when a task opens - #25179: stale subagents accumulate in the Desktop app - #25341: stale `open` spawn edges - #29590: Desktop becomes unresponsive opening previous conversations Thread titles, IDs, paths and conversation contents are omitted. I can provide sanitised logs or additional database summaries if useful.", "url": "https://github.com/openai/codex/issues/38250", "createdAt": "2026-08-12T21:12:23Z", "updatedAt": "2026-08-13T01:09:55Z", "timestamp": "2026-08-13T01:09:55Z", "metrics": { "reactions": 0, "comments": 3 }, "labels": [ "bug", "app", "subagent" ], "author": "phillbee", "state": "open", "assignees": [] }, { "id": "github:openai/codex:issue:38254", "source": "github", "group": "coding-agent-infrastructure", "project": "openai/codex", "kind": "issue", "title": "[Linux] Desktop app fails to launch when stale Codex SingletonLock points to a dead PID", "text": "### Summary On Ubuntu 26.04, the ChatGPT/Codex Linux desktop app refused to launch because the Codex profile was reported as being in use by another process, even though the referenced PID no longer existed and no `chatgpt` or `codex` processes were running. Removing only the stale Chromium/Electron singleton files under `~/.config/Codex/` immediately fixed the problem and the app launched successfully. ### Environment - Ubuntu 26.04 (Resolute Raccoon) x86_64 - Kernel: Linux 7.0.0-29-generic - GNOME 50.1 - Mutter / Wayland - CPU: AMD Ryzen 7 5800X3D - GPU: NVIDIA RTX 3080 - Codex app-server after successful launch: `0.147.0-alpha.6.6` - Launch command: `chatgpt` Context: this occurred after updating the NVIDIA driver and rebooting. I do **not** know whether the driver update caused the stale lock; it may simply have coincided with an unclean app/session shutdown. ### Actual behavior Launching `chatgpt` failed with: ```text ERROR:chrome/browser/process_singleton_posix.cc:365] The profile appears to be in use by another Codex process (199157) on another computer (jyoush-To-Be-Filled-By-O-E-M). Codex has locked the profile so that it doesn't get corrupted. If you are sure no other processes are using this profile, you can unlock the profile and relaunch Codex. ERROR:chrome/browser/ui/views/message_box_dialog.cc:200] Unable to show message box: Codex - The profile appears to be in use by another Codex process (199157) ... ``` The app exited instead of recovering or presenting a usable unlock flow. ### Verification The PID referenced by the lock did not exist: ```text $ ps -fp 199157 UID PID PPID C STIME TTY TIME CMD ``` No ChatGPT/Codex processes were running: ```text $ pgrep -af 'chatgpt' $ pgrep -af 'codex' $ pgrep -af 'chatgpt|codex' ``` The stale singleton files were still present: ```text /home/jyoush/.config/Codex/SingletonSocket /home/jyoush/.config/Codex/SingletonLock /home/jyoush/.config/Codex/SingletonCookie ``` ### Workaround that fixed it ```bash rm -f ~/.config/Codex/SingletonSocket ~/.config/Codex/SingletonLock ~/.config/Codex/SingletonCookie chatgpt ``` After removing those three files, the app launched normally. The bundled Codex process spawned and initialized successfully, including: ```text [StdioConnection] stdio_transport_spawned ... executablePath=/usr/lib/chatgpt/resources/codex [AppServerConnection] Current reported app-server version: currentVersion=0.147.0-alpha.6.6 [AppServerConnection] Codex CLI initialized [window-manager] window ready-to-show ``` ### Expected behavior If the owner PID recorded by the singleton lock no longer exists, the Linux desktop app should detect that the lock is stale and recover automatically, or provide a working prompt/action to unlock the profile. It should not remain permanently unable to launch until the user manually deletes `SingletonLock`, `SingletonSocket`, and `SingletonCookie`. ### Additional note The log also shows `Unable to show message box`, so the intended recovery UI may itself be failing on Linux/Wayland.", "url": "https://github.com/openai/codex/issues/38254", "createdAt": "2026-08-12T21:30:48Z", "updatedAt": "2026-08-12T21:37:49Z", "timestamp": "2026-08-12T21:37:49Z", "metrics": { "reactions": 0, "comments": 1 }, "labels": [ "bug", "app" ], "author": "jyoush", "state": "open", "assignees": [] }, { "id": "github:openai/codex:issue:38255", "source": "github", "group": "coding-agent-infrastructure", "project": "openai/codex", "kind": "issue", "title": "[app] “Sort chats by” options do not reorder project groups in the sidebar", "text": "### What version of the Codex App are you using (From “About Codex” dialog)? 26.803.81509 (build 6415) ### What subscription do you have? ChatGPT Pro 20x ### What platform is your computer? Darwin 25.6.1 arm64 arm ### What issue are you seeing? When the sidebar is organized **By project**, changing **Sort chats by** between **Priority**, **Last updated**, and **Manual order** changes the selected checkmark, but the visible project-group order does not change. This has not worked for me since the feature was released. In particular, a project lower in the sidebar remains in the same position even after recent activity while **Last updated** is selected. The current wording is also ambiguous: if these options are intended to sort only chats within each project group, the app does not provide a corresponding way to sort the project groups themselves. ### What steps can reproduce the bug? 1. Open the Codex desktop app with multiple projects. 2. Open the sidebar organization menu. 3. Select **By project**. 4. Select **Last updated** under **Sort chats by**. 5. Work in a project that is lower in the sidebar. 6. Observe that the project group does not move according to its recent activity. 7. Switch between **Priority**, **Last updated**, and **Manual order**. 8. Observe that the checkmark changes, but the project-group order remains unchanged. ### What is the expected behavior? When **By project** is active, the selected sorting mode should visibly reorder the project groups when the underlying activity or priority differs. If the existing options intentionally apply only to chats inside each project, the UI should state that scope clearly and provide a separate control for sorting project groups by priority, last updated, or manual order. ### Additional information The behavior is persistent rather than intermittent. Related reports: - #31836 - #33077 - #37733 No private paths, task IDs, project IDs, logs, or account details are included in this report.", "url": "https://github.com/openai/codex/issues/38255", "createdAt": "2026-08-12T21:38:24Z", "updatedAt": "2026-08-12T21:57:57Z", "timestamp": "2026-08-12T21:57:57Z", "metrics": { "reactions": 0, "comments": 1 }, "labels": [ "bug", "app", "session" ], "author": "omarpinarecords", "state": "closed", "assignees": [] }, { "id": "github:openai/codex:issue:38259", "source": "github", "group": "coding-agent-infrastructure", "project": "openai/codex", "kind": "issue", "title": "[app] Document manual project ordering and add project-folder sort controls", "text": "### What variant of Codex are you using? App — 26.803.81509 (build 6415), macOS Darwin 25.6.1 arm64, ChatGPT Pro 20x ### Summary Project folders/groups in the desktop sidebar **can already be reordered manually by dragging them**, and the custom order works. However, this behavior is not documented, and the surrounding UI is confusing: - Under **Organize sidebar → By project**, the menu says **Sort chats by**. - Its options are **Priority**, **Last updated**, and **Manual order**. - Manual drag-ordering of the project folders works, despite the control being labeled **Sort chats by**. - **Priority** and **Last updated** do not provide equivalent automatic sorting of the project folders/groups. This makes it unclear whether **Manual order** applies to chats, projects, or both, and it encourages users to expect the other sorting modes to reorder project groups too. ### What feature would you like to see? Please separate project-folder sorting from chat sorting. #### Sort projects by - **Priority** - **Last updated** - **Manual order** — preserve the existing drag-and-drop project ordering - **Name** — alphabetical by the visible project name #### Sort chats within projects by - **Priority** - **Last updated** - **Manual order** The existing **Sort chats by** label should be changed to **Sort chats within projects by**, or the project and chat controls should be visually separated. ### Expected behavior - **Project Manual order:** users can drag project folders into a custom order, that order persists, and the behavior is documented. - **Project Last updated:** unpinned projects are ordered by the latest activity of their contained chats. - **Project Priority:** projects containing chats that need attention are prioritized. - **Project Name:** unpinned projects are sorted alphabetically by their displayed name. - **Chat sorting:** remains independent and affects chats inside project groups. - **Pinned projects:** remain handled explicitly and predictably. ### Documentation gap Current official documentation describes pinning projects and sorting chats/Recents, but I could not find documentation for: - manually dragging project folders to reorder them; - when **Manual order** applies to project groups; - whether the project order persists; - how project-folder order relates to **Sort chats by**. Relevant official pages: - [Projects and chats](https://learn.chatgpt.com/docs/projects) - [Moving to the new ChatGPT desktop app](https://help.openai.com/en/articles/20001276) - [ChatGPT release notes](https://help.openai.com/en/articles/6825453-chatgpt-release-notes) ### Why clarification is needed The current behavior has produced repeated reports from users who reasonably expected **Priority** or **Last updated** to reorder project groups. Some reports characterize it as a regression; others request explicit project-level sorting. Related reports and requests: - #27753 — alphabetical project sorting - #31836 — Last updated sorts chats/tasks within groups but not the project groups - #31964 — projects and chats not sorting by last updated - #33077 — project sorting controls do not change project order - #33523 — recently used project sorting - #35124 — improved organization for many projects - #37733 — project sorting options do not reorder project groups ### Clarification of this request This issue is **not** requesting manual project ordering from scratch. Manual drag-ordering already works. The request is to: 1. document that existing behavior; 2. label its scope clearly; 3. provide separate automatic project-folder sorting by Priority, Last updated, and Name. No private paths, task IDs, project IDs, feedback IDs, logs, or account details are included.", "url": "https://github.com/openai/codex/issues/38259", "createdAt": "2026-08-12T22:06:38Z", "updatedAt": "2026-08-12T22:25:43Z", "timestamp": "2026-08-12T22:25:43Z", "metrics": { "reactions": 0, "comments": 1 }, "labels": [ "enhancement", "app" ], "author": "omarpinarecords", "state": "open", "assignees": [] }, { "id": "github:openai/codex:issue:38260", "source": "github", "group": "coding-agent-infrastructure", "project": "openai/codex", "kind": "issue", "title": "Project Workspaces with Shared Context Across Related Chats", "text": "### What variant of Codex are you using? Codex APP | ChatGPT with Codex ### What feature would you like to see? I'd like to propose an optional ****Project Workspace** ****feature that allows users to group a small number of related chats or Codex sessions--perhaps 3-5--into a shared workspace. Each chat would remain an independent conversation focused on a specific part of a larger project, while being able to access a controlled set of shared project context. For example, a technical project could contain: - **Development Chat** - application code, scripts, APIs, and debugging - **Networking Chat** - network design, VLANs, routing, firewalls, infrastructure, and troubleshooting - **Documentation Chat** - README files, technical documentation, diagrams, and procedures - **Planning Chat** - requirements, architecture decisions, milestones, and project goals The important distinction is that these chats would **not be merged into one large conversation**. Each would retain its own history and specialized focus. Instead, they could share a project-level context containing information such as: - Project goals and instructions - Shared notes - Uploaded files - Technical requirements - Architecture information - Important decisions - Environment details Users should remain in control of what is shared. For example, information discovered in one chat could have an **\"Add to Project Context\"** option rather than automatically exposing the entire conversation history to every other chat. A Development Chat could therefore learn an important networking decision from the shared project context without needing access to the Networking Chat's complete conversation history. Conceptually: Project Workspace │ ├── Shared Project Context │ ├── Goals │ ├── Instructions │ ├── Notes │ ├── Files │ ├── Requirements │ └── Important Decisions │ ├── Development Chat ├── Networking Chat ├── Documentation Chat └── Planning Chat Relevant workspace information could be retrieved when needed rather than injecting every conversation into every prompt. This could reduce repetition, keep complex projects organized, prevent individual conversations from becoming extremely long, improve context relevance, and give users explicit control over what information is shared between related chats. The core idea is: **Multiple focused conversations collaborating around a controlled set of shared project context while remaining independently organized.** ### Additional information I searched the existing issues before submitting this proposal and found a couple of related requests, particularly #35197 and #37085. I believe this proposal is related to, but distinct from, those requests. **#35197** focuses on unifying Chat, Work/Codex, Projects, and repository workflows into a single project workspace. **#37085** focuses on persistent, non-versioned project-level knowledge and context for Codex. This proposal focuses specifically on allowing **multiple independent, specialized chats or sessions within the same project to share a controlled project-level context without merging their conversation histories.** For example, a Development chat, Networking chat, Documentation chat, and Planning chat could remain separate while sharing selected project goals, files, notes, requirements, and decisions. I think these ideas could potentially complement each other: a persistent project-context layer could provide the shared knowledge, while separate chats or sessions could consume relevant portions of that context based on their individual roles. An important design goal would be user control. Rather than automatically sharing all conversation history, users could explicitly choose what becomes project-level knowledge and which chats are allowed to use it.", "url": "https://github.com/openai/codex/issues/38260", "createdAt": "2026-08-12T22:08:20Z", "updatedAt": "2026-08-12T22:09:37Z", "timestamp": "2026-08-12T22:09:37Z", "metrics": { "reactions": 0, "comments": 1 }, "labels": [ "enhancement", "app", "session", "memory" ], "author": "andycode94", "state": "open", "assignees": [] }, { "id": "github:openai/codex:issue:38262", "source": "github", "group": "coding-agent-infrastructure", "project": "openai/codex", "kind": "issue", "title": "cybersecutiy false positive", "text": "### What version of Codex CLI is running? codex-cli 0.147.0 ### What subscription do you have? enterprise ### Which model were you using? gpt-5.6-sol ### What platform is your computer? debian linux ### What terminal emulator and version are you using (if applicable)? none ### Codex doctor report ```json { \"schemaVersion\": 1, \"generatedAt\": \"1786572665s since unix epoch\", \"overallStatus\": \"ok\", \"codexVersion\": \"0.147.0\", \"checks\": { \"app_server.status\": { \"id\": \"app_server.status\", \"category\": \"app-server\", \"status\": \"ok\", \"summary\": \"background server is not running\", \"details\": { \"control socket\": \"/home/artur/.codex/app-server-control/app-server-control.sock\", \"daemon state dir\": \"/home/artur/.codex/app-server-daemon\", \"mode\": \"ephemeral\", \"pid file\": \"/home/artur/.codex/app-server-daemon/app-server.pid (missing)\", \"settings\": \"/home/artur/.codex/app-server-daemon/settings.json (missing)\", \"status\": \"not running\", \"update-loop pid file\": \"/home/artur/.codex/app-server-daemon/app-server-updater.pid (missing)\" }, \"remediation\": null, \"durationMs\": 0 }, \"auth.credentials\": { \"id\": \"auth.credentials\", \"category\": \"auth\", \"status\": \"ok\", \"summary\": \"auth is configured\", \"details\": { \"auth file\": \"/home/artur/.codex/auth.json\", \"auth storage mode\": \"File\", \"stored API key\": \"false\", \"stored ChatGPT tokens\": \"true\", \"stored agent identity\": \"false\", \"stored auth mode\": \"chatgpt\" }, \"remediation\": null, \"durationMs\": 0 }, \"config.load\": { \"id\": \"config.load\", \"category\": \"config\", \"status\": \"ok\", \"summary\": \"config loaded\", \"details\": { \"CODEX_HOME\": \"/home/artur/.codex\", \"config.toml\": \"/home/artur/.codex/config.toml\", \"config.toml parse\": \"ok\", \"cwd\": \"/home/artur\", \"enabled feature flags\": \"shell_tool, view_image, unified_exec, shell_snapshot, code_mode_host, terminal_resize_reflow, sqlite, hooks, enable_request_compression, multi_agent, apps, tool_search_always_defer_mcp_tools, tool_suggest, plugins, in_app_browser, in_app_updates, browser_use, browser_use_full_cdp_access, browser_use_external, computer_use, remote_plugin, plugin_sharing, image_generation, resize_all_images, item_ids, skill_mcp_dependency_install, skill_search, mentions_v2, steer, guardian_approval, goals, collaboration_modes, tool_call_mcp_elicitation, auth_elicitation, personality, fast_mode, tui_app_server, remote_compaction_v2, workspace_dependencies\", \"feature flag overrides\": \"none\", \"feature flags enabled\": \"39\", \"log dir\": \"/home/artur/.codex/log\", \"mcp servers\": \"1\", \"model\": \"gpt-5.6-sol\", \"model provider\": \"openai\", \"sqlite home\": \"/home/artur/.codex\" }, \"remediation\": null, \"durationMs\": 0 }, \"git.environment\": { \"id\": \"git.environment\", \"category\": \"git\", \"status\": \"ok\", \"summary\": \"git version 2.47.3\", \"details\": { \"PATH git #1\": \"/usr/bin/git\", \"PATH git #2\": \"/bin/git\", \"PATH git entries\": \"2\", \"git build options\": \"git version 2.47.3; cpu: x86_64; no commit associated with this build; sizeof-long: 8; sizeof-size_t: 8; shell-path: /bin/sh; libcurl: 8.14.1; zlib: 1.3.1\", \"git exec path\": \"/usr/lib/git-core\", \"git version\": \"git version 2.47.3\", \"repo detected\": \"false\", \"selected git\": \"/usr/bin/git\" }, \"remediation\": null, \"durationMs\": 29 }, \"installation\": { \"id\": \"installation\", \"category\": \"install\", \"status\": \"ok\", \"summary\": \"installation looks consistent\", \"details\": { \"PATH codex #1\": \"/home/artur/.local/npm-global/bin/codex\", \"current executable\": \"/home/artur/.local/npm-global/lib/node_modules/@openai/codex/node_modules/@openai/codex-linux-x64/vendor/x86_64-unknown-linux-musl/bin/codex\", \"install context\": \"npm (package /home/artur/.local/npm-global/lib/node_modules/@openai/codex/node_modules/@openai/codex-linux-x64/vendor/x86_64-unknown-linux-musl, bin /home/artur/.local/npm-global/lib/node_modules/@openai/codex/node_modules/@openai/codex-linux-x64/vendor/x86_64-unknown-linux-musl/bin, resources /home/artur/.local/npm-global/lib/node_modules/@openai/codex/node_modules/@openai/codex-linux-x64/vendor/x86_64-unknown-linux-musl/codex-resources, path /home/artur/.local/npm-global/lib/node_modules/@openai/codex/node_modules/@openai/codex-linux-x64/vendor/x86_64-unknown-linux-musl/codex-path)\", \"managed by bun\": \"false\", \"managed by npm\": \"true\", \"managed by pnpm\": \"false\", \"managed package root\": \"/home/artur/.local/npm-global/lib/node_modules/@openai/codex\", \"npm update target\": \"/home/artur/.local/npm-global/lib/node_modules/@openai/codex\" }, \"remediation\": null, \"durationMs\": 73 }, \"mcp.config\": { \"id\": \"mcp.config\", \"category\": \"mcp\", \"status\": \"ok\", \"summary\": \"MCP configuration is locally consistent\", \"details\": { \"configured servers\": \"1\", \"disabled servers\": \"0\", \"stdio servers\": \"1\" }, \"remediation\": null, \"durationMs\": 0 }, \"network.env\": { \"id\": \"network.env\", \"category\": \"network\", \"status\": \"ok\", \"summary\": \"network-related environment looks readable\", \"details\": { \"proxy env vars\": \"none\" }, \"remediation\": null, \"durationMs\": 0 }, \"network.provider_reachability\": { \"id\": \"network.provider_reachability\", \"category\": \"reachability\", \"status\": \"ok\", \"summary\": \"active provider endpoints are reachable over HTTP\", \"details\": { \"ChatGPT base URL\": \"https://chatgpt.com/backend-api/ reachable (HTTP 404)\", \"reachability mode\": \"ChatGPT auth\" }, \"remediation\": null, \"durationMs\": 177 }, \"network.websocket_reachability\": { \"id\": \"network.websocket_reachability\", \"category\": \"websocket\", \"status\": \"ok\", \"summary\": \"Responses WebSocket handshake succeeded\", \"details\": { \"DNS\": \"2 IPv4, 2 IPv6, first IPv4\", \"auth mode\": \"chatgpt\", \"connect timeout\": \"15000 ms\", \"endpoint\": \"wss://chatgpt.com/backend-api/\", \"handshake result\": \"HTTP 101 Switching Protocols\", \"model provider\": \"openai\", \"models etag present\": \"true\", \"provider name\": \"OpenAI\", \"proxy env vars\": \"none\", \"reasoning header\": \"false\", \"server model present\": \"false\", \"supports websockets\": \"true\", \"wire API\": \"responses\" }, \"remediation\": null, \"durationMs\": 687 }, \"runtime.provenance\": { \"id\": \"runtime.provenance\", \"category\": \"runtime\", \"status\": \"ok\", \"summary\": \"running npm on linux-x86_64\", \"details\": { \"commit\": \"unknown\", \"current executable\": \"/home/artur/.local/npm-global/lib/node_modules/@openai/codex/node_modules/@openai/codex-linux-x64/vendor/x86_64-unknown-linux-musl/bin/codex\", \"install method\": \"npm (package /home/artur/.local/npm-global/lib/node_modules/@openai/codex/node_modules/@openai/codex-linux-x64/vendor/x86_64-unknown-linux-musl, bin /home/artur/.local/npm-global/lib/node_modules/@openai/codex/node_modules/@openai/codex-linux-x64/vendor/x86_64-unknown-linux-musl/bin, resources /home/artur/.local/npm-global/lib/node_modules/@openai/codex/node_modules/@openai/codex-linux-x64/vendor/x86_64-unknown-linux-musl/codex-resources, path /home/artur/.local/npm-global/lib/node_modules/@openai/codex/node_modules/@openai/codex-linux-x64/vendor/x86_64-unknown-linux-musl/codex-path)\", \"platform\": \"linux-x86_64\", \"version\": \"0.147.0\" }, \"remediation\": null, \"durationMs\": 0 }, \"runtime.search\": { \"id\": \"runtime.search\", \"category\": \"search\", \"status\": \"ok\", \"summary\": \"search is OK (bundled)\", \"details\": { \"search command\": \"/home/artur/.local/npm-global/lib/node_modules/@openai/codex/node_modules/@openai/codex-linux-x64/vendor/x86_64-unknown-linux-musl/codex-path/rg\", \"search command readiness\": \"file exists\", \"search provider\": \"bundled\" }, \"remediation\": null, \"durationMs\": 0 }, \"sandbox.helpers\": { \"id\": \"sandbox.helpers\", \"category\": \"sandbox\", \"status\": \"ok\", \"summary\": \"sandbox configuration is readable\", \"details\": { \"approval policy\": \"OnRequest\", \"codex-linux-sandbox helper\": \"/home/artur/.codex/tmp/arg0/codex-arg0XSc7ni/codex-linux-sandbox\", \"execve wrapper helper\": \"/home/artur/.codex/tmp/arg0/codex-arg0XSc7ni/codex-execve-wrapper\", \"filesystem sandbox\": \"restricted\", \"network sandbox\": \"restricted\" }, \"remediation\": null, \"durationMs\": 0 }, \"state.paths\": { \"id\": \"state.paths\", \"category\": \"state\", \"status\": \"ok\", \"summary\": \"state paths and databases are inspectable\", \"details\": { \"CODEX_HOME\": \"/home/artur/.codex (dir)\", \"active rollout files\": \"389 files, 510405928 total bytes, 1312097 average bytes\", \"archived rollout files\": \"0 files, 0 total bytes, 0 average bytes\", \"goals DB\": \"/home/artur/.codex/goals_1.sqlite (file)\", \"goals DB integrity\": \"ok\", \"log DB\": \"/home/artur/.codex/logs_2.sqlite (file)\", \"log DB integrity\": \"ok\", \"log dir\": \"/home/artur/.codex/log (dir)\", \"memories DB\": \"/home/artur/.codex/memories_1.sqlite (file)\", \"memories DB integrity\": \"ok\", \"queue DB\": \"/home/artur/.codex/queue_1.sqlite (file)\", \"queue DB integrity\": \"ok\", \"sqlite home\": \"/home/artur/.codex (dir)\", \"state DB\": \"/home/artur/.codex/state_5.sqlite (file)\", \"state DB integrity\": \"ok\", \"thread history DB\": \"/home/artur/.codex/thread_history_1.sqlite (file)\", \"thread history DB integrity\": \"ok\" }, \"remediation\": null, \"durationMs\": 118 }, \"state.rollout_db_parity\": { \"id\": \"state.rollout_db_parity\", \"category\": \"threads\", \"status\": \"ok\", \"summary\": \"rollout files and state DB thread inventory agree\", \"details\": { \"default model provider\": \"openai\", \"rollout DB active files\": \"389\", \"rollout DB active rows\": \"389\", \"rollout DB archive mismatches\": \"0\", \"rollout DB archived files\": \"0\", \"rollout DB archived rows\": \"0\", \"rollout DB duplicate DB paths\": \"0\", \"rollout DB duplicate rollout thread ids\": \"0\", \"rollout DB malformed file names\": \"0\", \"rollout DB missing active rows\": \"0\", \"rollout DB missing archived rows\": \"0\", \"rollout DB model providers\": \"openai=389\", \"rollout DB rows\": \"389\", \"rollout DB scan cap reached\": \"false\", \"rollout DB scan errors\": \"0\", \"rollout DB sources\": \"cli=229, subagent:thread_spawn=160\", \"rollout DB stale rows\": \"0\" }, \"remediation\": null, \"durationMs\": 117 }, \"system.environment\": { \"id\": \"system.environment\", \"category\": \"system\", \"status\": \"ok\", \"summary\": \"OS language en-US\", \"details\": { \"EDITOR\": \"set\", \"LANG\": \"en_US.UTF-8\", \"LC_ALL\": \"en_US.UTF-8\", \"VISUAL\": \"set\", \"os\": \"Debian 13.0.0 (trixie) [64-bit]\", \"os language\": \"en-US\", \"os type\": \"Debian\", \"os version\": \"13.0.0\" }, \"remediation\": null, \"durationMs\": 5 }, \"terminal.env\": { \"id\": \"terminal.env\", \"category\": \"terminal\", \"status\": \"ok\", \"summary\": \"terminal metadata was detected\", \"details\": { \"COLORTERM\": \"truecolor\", \"DISPLAY\": \"present\", \"TERM\": \"tmux-256color\", \"TERM_PROGRAM\": \"VTE(8001)\", \"color output\": \"disabled (stdout is not a terminal)\", \"effective locale\": \"en_US.UTF-8\", \"multiplexer\": \"tmux 3.5a\", \"stderr is terminal\": \"true\", \"stdin is terminal\": \"true\", \"stdout is terminal\": \"false\", \"terminal\": \"unknown\", \"terminal size\": \"146x33\", \"tmux allow-passthrough\": \"off\", \"tmux client termname\": \"tmux-256color\", \"tmux client termtype\": \"VTE(8001)\", \"tmux extended-keys\": \"off\", \"tmux focus-events\": \"on\", \"tmux set-clipboard\": \"on\", \"tmux xterm-keys\": \"on\" }, \"remediation\": null, \"durationMs\": 19 }, \"terminal.title\": { \"id\": \"terminal.title\", \"category\": \"title\", \"status\": \"ok\", \"summary\": \"terminal title default\", \"details\": { \"terminal title activity\": \"true\", \"terminal title items\": \"activity, project-name\", \"terminal title project source\": \"cwd\", \"terminal title project value\": \"artur\", \"terminal title source\": \"default\" }, \"remediation\": null, \"durationMs\": 0 }, \"updates.status\": { \"id\": \"updates.status\", \"category\": \"updates\", \"status\": \"ok\", \"summary\": \"update configuration is locally consistent\", \"details\": { \"cached latest version\": \"0.147.0\", \"check for update on startup\": \"true\", \"last checked at\": \"2026-08-11T15:33:30.719645715Z\", \"latest version\": \"0.147.0\", \"latest version status\": \"current version is not older\", \"npm update target\": \"/home/artur/.local/npm-global/lib/node_modules/@openai/codex\", \"update action\": \"npm install -g @openai/codex\", \"version cache\": \"/home/artur/.codex/version.json\" }, \"remediation\": null, \"durationMs\": 422 } } } ``` ### What issue are you seeing? This content can't be shown We take extra caution with cybersecurity requests. If you’re a security professional, you may be able to apply for Trusted Access. Trusted Access: https://openai.com/form/enterprise-trusted-access-for-cyber/ Learn more: https://help.openai.com/en/articles/20001326 ### What steps can reproduce the bug? Uploaded thread: 019ff7ac-f3b3-7c91-82d0-cf85c318f8c8 ### What is the expected behavior? just let me do my work ### Additional information _No response_", "url": "https://github.com/openai/codex/issues/38262", "createdAt": "2026-08-12T22:12:16Z", "updatedAt": "2026-08-12T23:06:59Z", "timestamp": "2026-08-12T23:06:59Z", "metrics": { "reactions": 0, "comments": 2 }, "labels": [ "bug", "CLI", "safety-check" ], "author": "amaciuszonek", "state": "closed", "assignees": [] }, { "id": "github:openai/codex:issue:38263", "source": "github", "group": "coding-agent-infrastructure", "project": "openai/codex", "kind": "issue", "title": "excessive full screenscreen shots -", "text": "### What version of Codex CLI is running? latest ### What subscription do you have? k12 student ### Which model were you using? _No response_ ### What platform is your computer? _No response_ ### What terminal emulator and version are you using (if applicable)? _No response_ ### Codex doctor report ```json ``` ### What issue are you seeing? spectacle takes full screen, sometimes fails to target the window \"Image\" also this prompt tries to search for a clinic for new reason at all? like why? thats it, it completely takes fullscreen screens shots ### What steps can reproduce the bug? you cant reproduce the bug, the mods like to use heavy drugs, it will randomally take a fullscreen screenshot- wayland issue to solve this you should put a commit in wayland for mcp / llm bullshit ### What is the expected behavior? _No response_ ### Additional information _No response_", "url": "https://github.com/openai/codex/issues/38263", "createdAt": "2026-08-12T22:17:52Z", "updatedAt": "2026-08-12T22:21:52Z", "timestamp": "2026-08-12T22:21:52Z", "metrics": { "reactions": 0, "comments": 2 }, "labels": [ "bug", "CLI", "computer-use" ], "author": "glook9001", "state": "open", "assignees": [] }, { "id": "github:openai/codex:issue:38264", "source": "github", "group": "coding-agent-infrastructure", "project": "openai/codex", "kind": "issue", "title": "Codex iOS SSH disconnects before authentication with exe.dev RSA host certificate", "text": "### What issue are you seeing? The Codex iOS **Add SSH Host** flow disconnects in roughly 500 ms, before SSH authentication completes, when connecting to an exe.dev VM through exe.dev's managed SSH endpoint. The iOS UI reports only: > Could not connect to @.exe.xyz over SSH. This appears to be an interoperability problem in the iOS SSH client with exe.dev's RSA OpenSSH host certificate. The same iPhone, hostname, username, and private key work in Termius. ### Environment - Client: Codex/ChatGPT iOS app (current App Store build as of August 13, 2026) - Host: exe.dev VM at `.exe.xyz:22` - Remote SSH implementation banner: `Go` - User authentication: public key - Server host-key algorithm selected by OpenSSH: `rsa-sha2-512-cert-v01@openssh.com` - Host certificate type: `ssh-rsa-cert-v01@openssh.com` - Host certificate ID: `exe-dev-host` - CA: `ssh-ed25519 SHA256:x6vfPQUYyUMtcHUbotV89qx0jfyz6XJHm7y00780nEI` - Host-key fingerprint: `SHA256:JJOP/lwiBGOMilfONPWZCXUrfK154cnJFXcqlsi6lPo` The fingerprint matches exe.dev's published host-key documentation: https://exe.dev/docs/faq/host-key ### Steps to reproduce 1. Create or use an exe.dev VM. 2. In the Codex iOS app, add an SSH host using: - Host: `.exe.xyz` - Port: `22` - Username: the exe.dev account username - Authentication: an unencrypted supported private key 3. Tap **Retry** or connect to the host. 4. The app disconnects after approximately 500 ms. ### Expected behavior The app should complete SSH host-key verification, authenticate with the supplied private key, and start the remote Codex bootstrap flow. ### Actual behavior The app disconnects before the VM receives an authenticated SSH session. No bootstrap command or app-server proxy process is created. ### Controls and diagnostics #### The same key works from the same iPhone Using Termius on the same iPhone with the exact same hostname, port, username, and private key succeeds. Running `echo hello` on the VM works. #### Two supported user-key formats were tested Both of these fail identically in Codex iOS: 1. Unencrypted PKCS#8 Ed25519 private key 2. Unencrypted SEC1 ECDSA P-256 private key Both public keys were registered with exe.dev. The ECDSA key was also verified independently with: ```sh ssh -o IdentitiesOnly=yes -o IdentityAgent=none \\ -i codex-ios-ecdsa-p256-test.pem \\ @.exe.xyz 'echo ECDSA_TEST_OK' ``` Result: ``` ECDSA_TEST_OK ``` Changing only the user-key algorithm did not change the iOS failure, so this does not appear to be an Ed25519 private-key parsing problem. #### No SSH session is created during the iOS retry While tapping Retry, the VM process table was sampled every 50 ms for new `sshd-session` and `codex app-server proxy` processes. No new process appeared. By contrast, successful OpenSSH and Termius connections create an `sshd-session` immediately. This places the failure before successful user authentication and before all Codex bootstrap logic. #### The remote Codex app server is healthy Separately verified on the VM: - Managed app-server version: `0.147.0` - Unix control socket exists and is in `LISTEN` - Both Codex CLI `0.144.5` and `0.147.0` proxies receive: `HTTP/1.1 101 Switching Protocols` - The app-server has successfully run normal Codex threads. Therefore this is not caused by `PATH`, `nc -U`, socket permissions, stale locks, or app-server version mismatch. The failing iOS attempt never reaches those layers. #### Server KEX proposal OpenSSH reports: ``` KEX algorithms: mlkem768x25519-sha256, curve25519-sha256, curve25519-sha256@libssh.org, ecdh-sha2-nistp256, ecdh-sha2-nistp384, ecdh-sha2-nistp521, diffie-hellman-group14-sha256, diffie-hellman-group14-sha1 Host key algorithms: rsa-sha2-256, rsa-sha2-512, ssh-rsa, rsa-sha2-256-cert-v01@openssh.com, rsa-sha2-512-cert-v01@openssh.com, ssh-rsa-cert-v01@openssh.com Ciphers: aes128-gcm@openssh.com, aes256-gcm@openssh.com, chacha20-poly1305@openssh.com, aes128-ctr, aes192-ctr, aes256-ctr ``` OpenSSH negotiates: ``` kex: algorithm: ecdh-sha2-nistp256 kex: host key algorithm: rsa-sha2-512-cert-v01@openssh.com ``` ### Suspected cause This is an inference from the evidence above: the iOS SSH implementation may advertise or select an RSA OpenSSH host-certificate algorithm but then fail while parsing or validating the certificate, terminating before user authentication. The server also offers non-certificate RSA host-key algorithms, but Codex iOS does not expose a way to control `HostKeyAlgorithms` or obtain a detailed SSH error. ### Relationship to existing issues This is distinct from #22831 and #23102: - In those reports, SSH authentication succeeds and the iOS client reaches `codex`, app-server, or `nc -U`. - Here, no authenticated SSH session reaches the VM at all. - OpenBSD netcat with Unix-socket support is already installed and verified. ### Suggested improvements 1. Support and test RSA OpenSSH host certificates in the iOS SSH client, including `rsa-sha2-512-cert-v01@openssh.com`. 2. If certificate validation is unsupported, do not advertise/prefer certificate host-key algorithms; negotiate one of the server's plain RSA host keys instead. 3. Surface the underlying SSH negotiation/verification error in the iOS UI.", "url": "https://github.com/openai/codex/issues/38264", "createdAt": "2026-08-12T22:20:34Z", "updatedAt": "2026-08-12T22:26:26Z", "timestamp": "2026-08-12T22:26:26Z", "metrics": { "reactions": 0, "comments": 1 }, "labels": [ "bug", "iOS", "connectivity", "remote" ], "author": "mio256", "state": "open", "assignees": [] }, { "id": "github:openai/codex:issue:38266", "source": "github", "group": "coding-agent-infrastructure", "project": "openai/codex", "kind": "issue", "title": "Codex Security plugin burned through 60–70% of my weekly quota on 200$ plan with no results", "text": "### What version of the Codex App are you using (From “About Codex” dialog)? Powered by Codex & OWL Version 26.803.61601 Released Aug 9, 2026 ### What subscription do you have? 200 ### What platform is your computer? Mac m4 ### What issue are you seeing? Sorry for AI written post but it's better than I'm in explaining the issue clearly. So today I launched the Security plugin in Codex and something went wrong. I'm on the latest version of the desktop app, on mac. At first, the security scan reported that my CLI was outdated. I updated the CLI and started the scan again. It then ran for around 3 hours without returning results and at that point I steered the agent and told it to stop/close the scan if it couldn't return any results within the next 15 minutes. 15 minutes later, Codex told me it was no longer watching the process but the process itself apparently kept running in the background. Eventually it reported that the process had terminated which happened due to my subscription usage limit being completely exhausted by it. Before starting this, I had around 60–70% of my weekly quota left. The usage dashboard says 91% of today's usage came from the SDK. And after all of that, the security scan still didn't produce any result. Literally nothing. It;s just long scroll of \"its still working\" messages. It looks like either the underlying process continued consuming tokens after the agent stopped watching it, or something got stuck in a runaway loop. ### What steps can reproduce the bug? Feedback ID: 019ff558-5195-72e3-929d-d02aa855af0d ### What is the expected behavior? _No response_ ### Additional information _No response_", "url": "https://github.com/openai/codex/issues/38266", "createdAt": "2026-08-12T22:32:24Z", "updatedAt": "2026-08-13T02:59:00Z", "timestamp": "2026-08-13T02:59:00Z", "metrics": { "reactions": 0, "comments": 2 }, "labels": [ "bug", "rate-limits", "app", "skills" ], "author": "jMerta", "state": "open", "assignees": [] }, { "id": "github:openai/codex:issue:38267", "source": "github", "group": "coding-agent-infrastructure", "project": "openai/codex", "kind": "issue", "title": "Support for Background Compaction", "text": "### What variant of Codex are you using? App ### What feature would you like to see? Compaction currently pauses the agent loop while the previous context is compacted. Codex could make compaction time completely hidden if the agent is allowed to continue working during this time. This involves 1. Taking a snapshot of the conversation and sending it to the compaction endpoint. 2. While that happens, the agent should continue working. 3. When the compacted context is ready, it should replace the context up to the snapshot point. This is already [implemented in GH Copilot](https://docs.github.com/en/copilot/concepts/agents/copilot-cli/context-management#what-compaction-does). ### Additional information _No response_", "url": "https://github.com/openai/codex/issues/38267", "createdAt": "2026-08-12T22:41:01Z", "updatedAt": "2026-08-12T22:41:37Z", "timestamp": "2026-08-12T22:41:37Z", "metrics": { "reactions": 0, "comments": 0 }, "labels": [ "enhancement", "context", "app" ], "author": "rmenon1008", "state": "open", "assignees": [] }, { "id": "github:openai/codex:issue:38269", "source": "github", "group": "coding-agent-infrastructure", "project": "openai/codex", "kind": "issue", "title": "Automatic compaction drops unchanged additionalContext", "text": "### What issue are you seeing? Unchanged client-supplied `additionalContext` disappears after automatic compaction. Codex retains `additionalContext` in `AdditionalContextStore` and normally emits only entries that changed since the prior turn. That deduplication works until compaction replaces model history: the replacement history is built without re-rendering the store's retained values. A subsequent model request therefore lacks still-active application context even though the client did not remove or change it. In our app-server-backed integration, this caused connected browser-profile context to vanish after compaction. The model then reported that no browser profile was active despite the client having supplied one earlier in the same session. ### What steps can reproduce the bug? The included integration test reproduces this through the real Responses API loop: 1. Submit a user turn with application `additionalContext`, such as `browser_access = \"profile id: browser-profile-1\"`. 2. Return a shell tool call with usage high enough to trigger automatic mid-turn compaction. 3. Return the compaction summary. 4. Inspect the continuation request sent to the model. Before the fix, the continuation request contains no `` developer context. The regression assertion fails with an empty list instead of: ```text profile id: browser-profile-1 ``` The same underlying omission exists when a token-budget rollover starts a replacement context window. ### What is the expected behavior? Every replacement context window should include the current values retained by `AdditionalContextStore`. Ordinary turns should continue deduplicating unchanged values, but compaction must rebuild active context because it discards the history that previously carried those values. ### Additional information A focused fix and regression test are ready on a branch based directly on current `openai/codex` `main`: - Commit: https://github.com/davidfant/codex/commit/a77285a05 - Branch: https://github.com/davidfant/codex/tree/codex/upstream-preserve-additional-context-compaction - Compare view: https://github.com/openai/codex/compare/main...davidfant:codex:codex/upstream-preserve-additional-context-compaction - Downstream merged fix: https://github.com/comp-work/openai-codex/pull/57 The change renders the store's current values into standard local/remote compaction replacement history and token-budget context-window replacement history. It touches four files and preserves normal per-turn deduplication. Focused validation on current upstream: - `env -u CODEX_SANDBOX_NETWORK_DISABLED NEXTEST_RETRIES=0 just test -p codex-core suite::additional_context` — 7 passed - `env -u CODEX_SANDBOX_NETWORK_DISABLED NEXTEST_RETRIES=0 just test -p codex-core multiple_auto_compact_per_task_runs_after_token_limit_hit token_budget_context_uses_new_window_after_compaction` — 2 passed - `cargo fmt --all` - `git diff --check` The new E2E failed at the intended post-compaction assertion before the implementation and passed afterward. If a maintainer agrees with the approach and invites the contribution, the clean branch is ready to open as a PR.", "url": "https://github.com/openai/codex/issues/38269", "createdAt": "2026-08-12T22:57:23Z", "updatedAt": "2026-08-12T22:58:02Z", "timestamp": "2026-08-12T22:58:02Z", "metrics": { "reactions": 0, "comments": 0 }, "labels": [ "bug", "context", "app-server" ], "author": "davidfant", "state": "open", "assignees": [] }, { "id": "github:openai/codex:issue:38271", "source": "github", "group": "coding-agent-infrastructure", "project": "openai/codex", "kind": "issue", "title": "Computer Use screenshot capture fails on Windows 10 Boot Camp with SetIsBorderRequired E_NOINTERFACE (0x80004002)", "text": "### What issue are you seeing? ## Summary Computer Use cannot capture screenshots on Windows 10 22H2 running through Apple Boot Camp. Application and window enumeration works correctly, but every `get_window_state` request that includes a screenshot fails with: ```text SetIsBorderRequired failed: No such interface supported (0x80004002) ``` The problem is reproducible with ordinary Windows applications, including the Windows Settings app. It is therefore not specific to a particular application, game, rendering engine, fullscreen mode, or third-party modification. This prevents Computer Use from visually inspecting any window or safely performing coordinate-based interactions. ## Environment - Platform: Codex Desktop for Windows - Operating system: Windows 10 22H2 - OS build family: 19045 - Installation environment: Apple Boot Camp - Computer Use plugin: `26.803.81509` - Target applications tested: - Windows Settings - Standard desktop applications - Hardware-accelerated applications Windows 11 is not a practical workaround because the affected computer runs Windows through Boot Camp, for which Windows 10 is the normally supported configuration on this hardware. ### What steps can reproduce the bug? ## Steps to reproduce 1. Start Codex Desktop on Windows 10 22H2. 2. Enable or invoke the Computer Use plugin. 3. List available applications: ```javascript const apps = await sky.list_apps(); ``` 4. Select a window returned by `list_apps()`. For example, select the Windows Settings window. 5. Rehydrate the returned window: ```javascript const targetWindow = await sky.get_window({ id: returnedWindow.id, app: returnedWindow.app, }); ``` 6. Request a screenshot-backed window state: ```javascript await sky.get_window_state({ window: targetWindow, include_screenshot: true, include_text: false, }); ``` 7. The request fails before returning a screenshot. The same failure occurs with the default screenshot request: ```javascript await sky.get_window_state({ window: targetWindow, }); ``` ### What is the expected behavior? ## Actual behavior Every screenshot-enabled state request fails with: ```text SetIsBorderRequired failed: No such interface supported (0x80004002) ``` No screenshot or screenshot ID is returned. Computer Use can still: - list installed and running applications; - enumerate open windows; - return valid window IDs, process identifiers, and titles; - select and rehydrate a target window; - use portions of the non-visual accessibility path. Computer Use cannot: - capture the selected window; - visually inspect its contents; - derive reliable coordinates; - safely perform screenshot-based clicks, scrolling, or dragging; - verify the result of a visual interaction. Computer Use should detect whether `GraphicsCaptureSession.IsBorderRequired` is supported before attempting to set it. If the property is unavailable, Computer Use should either: 1. continue without modifying the capture-border setting; or 2. use a compatible screenshot fallback. An unsupported optional border property should not abort the entire screenshot request. ## Expected behavior Computer Use should detect whether `GraphicsCaptureSession.IsBorderRequired` is supported before attempting to set it. If the property is unavailable, Computer Use should either: 1. continue without modifying the capture-border setting; or 2. use a compatible screenshot fallback. An unsupported optional border property should not abort the entire screenshot request. ### Additional information ## Troubleshooting already performed The following tests did not change the result: - Restarted Codex Desktop. - Restarted the target applications. - Performed a complete Windows reboot. - Disabled third-party overlays. - Tested multiple unrelated applications. - Tested the standard Windows Settings application. - Tested foreground and background windows. - Ensured Codex and the target applications were running at the same privilege level. - Disabled fullscreen behavior and fullscreen optimizations where applicable. - Removed application-specific modifications from the test environment. - Confirmed that Computer Use still enumerates applications and windows correctly. Because Windows Settings produces the same error, the failure appears to be inside the Computer Use screenshot implementation rather than the target application. ## Suspected cause The behavior is consistent with Computer Use calling: ```text GraphicsCaptureSession.IsBorderRequired ``` on a Windows version whose available API contract does not expose that property. Windows then returns: ```text E_NOINTERFACE (0x80004002) ``` The screenshot implementation appears to treat this optional-property failure as fatal instead of continuing without changing the capture border. This also explains why enumeration and non-visual operations remain functional while every screenshot-enabled request fails immediately. ## Suggested fix At minimum, Computer Use should check for property support before calling `SetIsBorderRequired`. For example, the implementation could use an API availability check equivalent to: ```text ApiInformation.IsPropertyPresent( \"Windows.Graphics.Capture.GraphicsCaptureSession\", \"IsBorderRequired\" ) ``` If unavailable, it should skip the border-setting call and continue with the default capture-border behavior. For more robust Windows 10 support, the capture pipeline could operate as follows: 1. Attempt the normal Windows Graphics Capture path. 2. Skip `SetIsBorderRequired` when the property is unavailable. 3. If Windows Graphics Capture fails or times out, fall back to `PrintWindow` with `PW_RENDERFULLCONTENT`. 4. If `PrintWindow` returns an empty or black frame, fall back to `BitBlt` with `SRCCOPY | CAPTUREBLT`. 5. Return the fallback image through the normal Computer Use screenshot interface. 6. Synchronize the native input state before performing coordinate actions based on a fallback screenshot. 7. Ensure temporary fallback screenshot IDs are not passed incorrectly to components that only recognize native screenshot IDs. If fallback capture is not supported, Computer Use should at least return a clear compatibility message instead of exposing the internal `SetIsBorderRequired` error. ## Impact This is a complete blocker for visual Computer Use workflows on the affected system. The plugin can identify the correct application and window, but it cannot inspect the window contents. Sending coordinate input without a screenshot would be unsafe and unreliable. The issue is particularly significant for Boot Camp users because upgrading to Windows 11 is often unsupported or impractical on otherwise functional hardware. A compatibility check around this optional Windows API property would restore at least the normal capture attempt for Windows 10 users. ## Related issue This appears related to: https://github.com/openai/codex/issues/25178 I am opening a separate report to provide an additional independent reproduction using: - a newer Computer Use plugin version; - Apple Boot Camp; - multiple unrelated target windows; - a complete reboot and environmental troubleshooting; - reproduction against the standard Windows Settings application. The issue remains reproducible with Computer Use plugin version `26.803.81509`.", "url": "https://github.com/openai/codex/issues/38271", "createdAt": "2026-08-12T23:01:20Z", "updatedAt": "2026-08-12T23:02:00Z", "timestamp": "2026-08-12T23:02:00Z", "metrics": { "reactions": 0, "comments": 0 }, "labels": [ "bug", "windows-os", "app", "computer-use" ], "author": "willyansete7", "state": "open", "assignees": [] }, { "id": "github:openai/codex:issue:38273", "source": "github", "group": "coding-agent-infrastructure", "project": "openai/codex", "kind": "issue", "title": "Expose safe project and thread ordering APIs for Codex Desktop", "text": "### What variant of Codex are you using? App / Codex Desktop ### What feature would you like to see? Codex Desktop supports drag-and-drop organization, but automating it through the UI is unsafe because dropping a thread onto a project changes its project membership instead of merely changing its visual order. Please expose supported App Server APIs for: - reading the persisted project and thread display order; - assigning an explicit order or moving an item before/after another item; - sorting projects and threads by recent activity; - distinguishing reorder operations from moving a thread between projects; - applying an atomic batch reorder; - returning the resulting order for verification; - preserving thread-to-project membership during reorder; - restoring a previous order after failure. ### Use case Users with many long-running projects need external local organizers that can rank projects and threads by activity without editing internal files or using fragile mouse automation. A supported ordering API would also make accessibility tooling and local workflow automation substantially safer. The key requirement is that a visual reorder must never be confused with changing a thread's project membership.", "url": "https://github.com/openai/codex/issues/38273", "createdAt": "2026-08-12T23:19:17Z", "updatedAt": "2026-08-12T23:20:47Z", "timestamp": "2026-08-12T23:20:47Z", "metrics": { "reactions": 0, "comments": 1 }, "labels": [ "enhancement", "app", "app-server" ], "author": "root1739126979", "state": "open", "assignees": [] }, { "id": "github:openai/codex:issue:38277", "source": "github", "group": "coding-agent-infrastructure", "project": "openai/codex", "kind": "issue", "title": "[Bug] Multi-Agent V2 child gets service_tier=priority after parent switches to default, even when spawn_agent omits the field", "text": "### What version of Codex is running? - Codex Desktop: `26.803.10989.0` - Embedded Codex runtime recorded in the child rollout: `0.147.0-alpha.6.6` ### What subscription do you have? ChatGPT Pro (20x) ### Which model were you using? `gpt-5.6-sol`, reasoning effort `ultra`, Multi-Agent V2 ### What platform is your computer? Microsoft Windows 11 Home, version `10.0.26200`, x64 ### What issue are you seeing? A parent thread had previously used Fast, then was switched back to Standard. Its effective thread setting and global config both recorded `service_tier = \"default\"`. More than two hours after the parent applied `default`, it spawned a child. The actual `spawn_agent` function call omitted `service_tier` entirely; its argument keys were exactly: ```text task_name,fork_turns,message ``` Despite that, the newly created child received `service_tier: \"priority\"` immediately before `task_started`. In the model catalog and UI, `priority` maps to Fast. This is materially different from reports where the model-generated `spawn_agent` call explicitly contains `service_tier: \"priority\"`. Here, the field was absent from the call, yet the Desktop/Multi-Agent V2 child initialization still applied Fast. ### Sanitized rollout evidence Global config at the time: ```toml model = \"gpt-5.6-sol\" model_reasoning_effort = \"ultra\" service_tier = \"default\" multi_agent = true ``` The latest parent `thread_settings_applied` event before the affected spawn: ```json { \"timestamp\": \"2026-08-12T15:33:54.725Z\", \"model\": \"gpt-5.6-sol\", \"service_tier\": \"default\", \"reasoning_effort\": \"ultra\" } ``` The parent spawn call approximately two hours later: ```json { \"timestamp\": \"2026-08-12T17:38:57.519Z\", \"name\": \"spawn_agent\", \"arguments\": { \"task_name\": \"\", \"fork_turns\": \"3\", \"message\": \"\" } } ``` The new child session metadata: ```json { \"timestamp\": \"2026-08-12T17:39:02.510Z\", \"originator\": \"Codex Desktop\", \"cli_version\": \"0.147.0-alpha.6.6\", \"multi_agent_version\": \"v2\" } ``` The child's effective settings, followed by task start: ```json { \"timestamp\": \"2026-08-12T17:39:02.549Z\", \"type\": \"thread_settings_applied\", \"thread_settings\": { \"model\": \"gpt-5.6-sol\", \"service_tier\": \"priority\", \"reasoning_effort\": \"ultra\" } } { \"timestamp\": \"2026-08-12T17:39:02.577Z\", \"type\": \"task_started\" } ``` The relevant local rollout records are parent lines 77913 and 80467, and child lines 814–815. Project path, task text, and thread IDs are redacted from this public report. ### Steps that reproduce the observed state 1. Configure `service_tier = \"default\"`. 2. In a long-running Desktop parent thread, use Fast and then switch the parent back to Standard. 3. Verify the parent emits `thread_settings_applied` with `service_tier: \"default\"`. 4. Spawn a bounded Multi-Agent V2 child without passing a `service_tier` field. 5. Inspect the child rollout before its first turn. 6. Observe `thread_settings_applied` with `service_tier: \"priority\"` immediately before `task_started`. The behavior may depend on a parent thread that previously used Fast, so a fresh Standard-only thread may not reproduce it. ### What is the expected behavior? When `spawn_agent` omits `service_tier`, a new child should inherit the parent's current effective tier. After the parent switches to `default`, every subsequently spawned child should start with `default`. A stale historical Fast setting should never override the current parent setting, and a quota-affecting tier change should be visible before child inference begins. ### Why this is severe Official OpenAI documentation says GPT-5.6 Fast consumes credits at 2.5x the Standard rate: https://learn.chatgpt.com/docs/agent-configuration/speed During the incident, the account UI showed a 47-percentage-point weekly usage drop over roughly two hours of multi-agent work. Exact attribution requires backend telemetry, but the rollout proves that affected children were sent through `priority` despite the parent being Standard and the spawn calls omitting the tier field. ### Related issues and key distinction - #29940 — subagents sometimes spawned with `service_tier=priority` - #30407 — Codex App subagents use Fast despite Standard and fast opt-out - #30756 — model-generated spawn call may silently include `service_tier=priority` The suggested workaround in #30756 is to omit the `service_tier` field so the child inherits Standard. That workaround was already in effect in this trace: the field was absent, yet the child still started with `priority`. Possible areas to inspect are stale per-thread service-tier state, Desktop child-thread initialization, config snapshots used by Multi-Agent V2, and the app-server settings applied between child creation and `task_started`.", "url": "https://github.com/openai/codex/issues/38277", "createdAt": "2026-08-13T00:07:07Z", "updatedAt": "2026-08-13T00:07:56Z", "timestamp": "2026-08-13T00:07:56Z", "metrics": { "reactions": 0, "comments": 0 }, "labels": [ "bug", "app", "subagent" ], "author": "allvegetable", "state": "open", "assignees": [] }, { "id": "github:openai/codex:issue:38279", "source": "github", "group": "coding-agent-infrastructure", "project": "openai/codex", "kind": "issue", "title": "Codex silently reduced a paper-replication task, then presented a smoke test as evidence about the paper being \"unsupported\"", "text": "### What issue are you seeing? I asked Codex to reproduce a research paper using the repository’s paper-replication skill, train on the supplied MS1M dataset, reproduce the paper’s attack evaluation, verify correctness, and use GPU 0. Instead of completing the requested experiment, Codex silently restricted MS1M to: max_classes: 512 max_per_class: 30 This reduced the available dataset from approximately 5.8 million images and 85,742 identities to only 13,528 images and 512 identities. It also shortened the paper’s training schedules and used substitute architectures and evaluation protocols. Codex then described the work as a reproduction and initially concluded that “the evidence does not support” some of the paper’s claims. Only after questioning the dataset size did it acknowledge that the run was merely a reduced-scale diagnostic and that the requested task was unfinished. The paper-replication skill did not request the 512-identity limit. Its instructions required paper-faithful baselines, explicit documentation of deviations, evidence before marking targets matched, and no completion claim until validation passed. ### What steps can reproduce the bug? It is hard to reproduce because of the randomness of LLMs, but here is what I did 1. Create a repository containing: - A research paper. - The Codex paper-replication skill. - Access to the paper’s requested training and evaluation datasets. 2. Ask Codex to: - Use the skill to reproduce the paper. - Train using the supplied full dataset. - Reproduce and verify the paper’s attack evaluation. - Use a specified GPU. 3. Observe whether Codex silently introduces dataset limits or shortened schedules to obtain a faster result. 4. Ask why the full dataset was not used. ### What is the expected behavior? Codex should: 1. Treat a reduced dataset or shortened schedule as a smoke test, never as the requested reproduction. 2. Ask for approval before materially reducing: - Dataset size. - Training duration. - Model fidelity. - Evaluation protocol. - Attack strength. 3. Clearly label experiment tiers, such as: - Smoke test. - Reduced-scale diagnostic. - Protocol-equivalent reproduction. - Full reproduction. 4. Continue to the full experiment when the requested data and compute are available. 5. If required resources are unavailable, report the task as blocked or unfinished. 6. Never interpret failure of a surrogate or reduced-scale implementation as evidence against the paper. 7. Reserve terms such as “reproduced,” “matched,” and “evidence does not support” for experiments satisfying the relevant fidelity and acceptance requirements. ### Additional information _No response_", "url": "https://github.com/openai/codex/issues/38279", "createdAt": "2026-08-13T00:16:06Z", "updatedAt": "2026-08-13T00:17:35Z", "timestamp": "2026-08-13T00:17:35Z", "metrics": { "reactions": 0, "comments": 1 }, "labels": [ "bug", "model-behavior", "skills" ], "author": "weathon", "state": "open", "assignees": [] }, { "id": "github:openai/codex:issue:38284", "source": "github", "group": "coding-agent-infrastructure", "project": "openai/codex", "kind": "issue", "title": "Reset card does not display specific expiration time", "text": "### What version of the Codex App are you using (From “About Codex” dialog)? 26.803.81509 ### What subscription do you have? puls ### What platform is your computer? windwos ### What issue are you seeing? Hello, I'd like to provide some feedback because I hope you can continue to improve and get better. I had a reset card that expired, and it showed the expiration date as the 13th. So on the 12th, I didn't use it for resetting. But when I opened it on the 13th, it was already gone. I'd like to suggest that you display the specific expiration time (not just the date), because these items are very precious to me, and I need to be able to use them at the very last moment. Thank you! ### What steps can reproduce the bug? Feedback ID: no-active-thread-019ff88d-6519-76f2-8acb-e83057f1116b ### What is the expected behavior? Expires on the 13th ### Additional information _No response_", "url": "https://github.com/openai/codex/issues/38284", "createdAt": "2026-08-13T00:40:16Z", "updatedAt": "2026-08-13T00:41:26Z", "timestamp": "2026-08-13T00:41:26Z", "metrics": { "reactions": 0, "comments": 1 }, "labels": [ "enhancement", "app" ], "author": "xulin303", "state": "open", "assignees": [] }, { "id": "github:openai/codex:issue:38286", "source": "github", "group": "coding-agent-infrastructure", "project": "openai/codex", "kind": "issue", "title": "macOS standalone: apply_patch fs helper re-exec through current symlink fails with EPERM", "text": "### What version of Codex CLI is running? `codex-cli 0.147.0` ### What subscription do you have? ChatGPT subscription ### Which model were you using? `gpt-5.6-sol` ### What platform is your computer? Apple Silicon macOS 26.6.1 (`Darwin 25.6.0 arm64`) ### What terminal emulator and version are you using (if applicable)? Ghostty 1.3.1 ### Codex doctor report The standalone installation was removed after diagnosis, so the full JSON report is no longer available. Before removal, the redacted summary reported: ```text Codex Doctor v0.147.0 · macos-aarch64 18 ok | 0 warn | 0 fail ok ``` ### What issue are you seeing? With the official standalone installation, `apply_patch` cannot update or delete an existing file under the normal restricted/workspace-write sandbox. Its filesystem helper tries to re-execute Codex through an installer-managed symlink and macOS Seatbelt rejects the exec with status 71: ```text apply_patch verification failed: Failed to read file to update /file: fs sandbox helper failed with status exit status: 71: sandbox-exec: execvp() of '/.codex/packages/standalone/current/codex' failed: Operation not permitted ``` The managed paths were: ```text /.local/bin/codex -> /.codex/packages/standalone/current/bin/codex /.codex/packages/standalone/current -> /.codex/packages/standalone/releases/0.147.0-aarch64-apple-darwin /.codex/packages/standalone/current/codex -> bin/codex ``` When the persistent remote-control daemon was running, errors named `standalone/current/codex`. After remote control was disabled and a fresh local CLI session was started, errors named `/.local/bin/codex`. Disabling remote control changed the visible executable path but did not fix the failure. Creating a new file could succeed, while the update/delete verification path failed before reading the existing file. The binary itself was healthy: - Direct execution outside Seatbelt returned `codex-cli 0.147.0`. - `codesign` showed a valid Developer ID signature from OpenAI OpCo, LLC. - The binary had no quarantine attribute. - Ownership and executable mode were normal. After uninstalling the standalone package and installing the Homebrew cask at the same `0.147.0` version, an identical `apply_patch` create/update/delete smoke test passed completely under workspace-write. ### What steps can reproduce the bug? 1. On Apple Silicon macOS, install the managed standalone package: ```sh curl -fsSL https://chatgpt.com/codex/install.sh | sh ``` 2. Start Codex through `/.local/bin/codex` in a repository using the normal restricted/workspace-write sandbox. 3. Ask Codex to update or delete an existing file with `apply_patch`. 4. Observe the filesystem-helper `sandbox-exec ... Operation not permitted` failure shown above. The failure was also isolated below `apply_patch`: - Launching the standalone binary directly outside the sandbox succeeded. - Launching `standalone/current/codex` inside a restricted `codex sandbox` profile failed with status 71, even after granting read access to the visible `current` directory and resolved release `bin` directory. - Launching the fully resolved `releases/0.147.0-aarch64-apple-darwin/bin/codex` path with the resolved release package readable succeeded and printed `codex-cli 0.147.0`. ### What is the expected behavior? `apply_patch` should create, update, and delete files inside the declared writable workspace when Codex is installed with the official standalone installer, as it does with the Homebrew cask. The filesystem helper should re-execute the active standalone binary without requiring `danger-full-access`. ### Additional information The relevant flow appears to be: - `codex-rs/exec-server/src/runtime_paths.rs`: `ExecServerRuntimePaths` makes the configured executable absolute but does not resolve its symlink chain. - `codex-rs/exec-server/src/fs_sandbox.rs`: the filesystem helper launches `runtime_paths.codex_self_exe` and derives helper read roots from that path. Inference: resolving the executable to its real release path for helper execution, and granting the resolved standalone package/runtime root in the generated Seatbelt profile, should fix the mismatch. A macOS regression test should use the installer layout (`.local/bin/codex -> standalone/current/bin/codex`, with `current` pointing to a versioned release). This is analogous to the Windows standalone junction/helper lookup problem in #30829, but it is a distinct macOS Seatbelt filesystem-helper re-exec failure. `codex doctor` could also include a sandboxed filesystem-helper smoke test; it reported all checks healthy while existing-file `apply_patch` operations failed.", "url": "https://github.com/openai/codex/issues/38286", "createdAt": "2026-08-13T00:57:37Z", "updatedAt": "2026-08-13T00:58:10Z", "timestamp": "2026-08-13T00:58:10Z", "metrics": { "reactions": 0, "comments": 0 }, "labels": [ "bug", "sandbox", "CLI", "tool-calls" ], "author": "adawalli", "state": "open", "assignees": [] }, { "id": "github:openai/codex:issue:38287", "source": "github", "group": "coding-agent-infrastructure", "project": "openai/codex", "kind": "issue", "title": "MCP tool results lose content when structuredContent is present (Codex App 26.803.81509)", "text": "### What version of the Codex App are you using (From “About Codex” dialog)? 26.803.81509 (build 6415) Also reproduced on 26.803.61601 (build 6396). After downgrading to 26.803.41515 (build 6321), the issue no longer reproduces. ### What subscription do you have? plus ### What platform is your computer? Darwin 24.6.0 arm64 arm ### What issue are you seeing? MCP tool call results lose their visible text (the content array) whenever the result also contains structuredContent. The transcription layer that converts MCP tool results into the assistant-visible function call output keeps only structuredContent and drops content entirely. Example: the built-in node_repl/js MCP server returns content: [{\"type\":\"text\",\"text\":\"REINSTALL_TEST 1786582832541\"}] structuredContent: {\"execution_duration_ms\":0} but the conversation only receives {\"execution_duration_ms\":0}. The text block is never visible to the assistant. Code still executes and side effects still happen, so this is purely an output-transcription bug. Session evidence (rollout logs in ~/.codex/sessions/2026/08/12/, same call_id): - mcp_tool_call_end (raw JSON-RPC result received from the MCP server): {\"Ok\": {\"content\": [{\"type\": \"text\", \"text\": \"REINSTALL_TEST 1786582832541\"}], \"structuredContent\": {\"execution_duration_ms\": 0}, \"isError\": false}} - function_call_output (what is actually sent to the model): Output: {\"execution_duration_ms\":0} So content is complete on the server side and lost in the app-side transcription. ### What steps can reproduce the bug? 1. In any Codex session, call the built-in node_repl/js MCP tool with: nodeRepl.write(\"x\"); 2. The tool executes fine, but the conversation only sees {\"execution_duration_ms\":0} instead of \"x\". 3. In the same session, node_repl/js_reset returns normally (it has no structuredContent field), which shows the bug only triggers when structuredContent is present. 4. Connecting directly to the node_repl binary over stdio (initialize -> notifications/initialized -> tools/call) returns the full content, confirming the MCP server itself is healthy. ### What is the expected behavior? content (the primary output per the MCP spec) should be preserved when transcribing MCP tool results. structuredContent is an optional extra field and should be merged with, or ignored in favor of, content. ### Additional information - The regression appeared between build 6321 (26.803.41515, Aug 7) and build 6396 (26.803.61601, Aug 10): the newer node_repl starts attaching structuredContent to js responses, which triggers the bug. Downgrading to 26.803.41515 makes it disappear. - Affects every tool routed through this MCP server, including the computer-use/@oai/sky underlying channel.", "url": "https://github.com/openai/codex/issues/38287", "createdAt": "2026-08-13T01:15:20Z", "updatedAt": "2026-08-13T01:16:50Z", "timestamp": "2026-08-13T01:16:50Z", "metrics": { "reactions": 0, "comments": 2 }, "labels": [ "bug", "mcp", "tool-calls", "app" ], "author": "eatmelonhan", "state": "open", "assignees": [] }, { "id": "github:openai/codex:issue:38289", "source": "github", "group": "coding-agent-infrastructure", "project": "openai/codex", "kind": "issue", "title": "App-server: expose atomic idle-only turn admission", "text": "### What variant of Codex are you using? CLI / app-server v2 on current `main` (`e766f7598993ce37cf61b9c26c80cc2ba3a4f2d7`). ### What feature would you like to see? An experimental app-server request that atomically starts a turn only when a specific thread is idle. Today, `turn/start` is intentionally start-or-steer: if a turn becomes active before Core admits the request, the input can be steered into that turn. A client can read an idle status first, but `thread/read → turn/start` is not atomic. That makes `turn/start` unsafe for background or event-driven clients that must never alter an active human-owned turn. A narrow v2 shape would be: ```text turn/startIfIdle { threadId, expectedCwd, clientUserMessageId?, input } ``` The admission should happen inside the same ordered Core turn-input path as ordinary input and either: - start one turn and return the existing `TurnStartResponse` with its actual turn ID; or - reject without steering, interrupting, queuing, applying turn settings, recording input, or making a provider request. The useful fail-closed reasons are: - thread is busy; - pending trigger work exists; - Plan mode is active for this client admission; - the effective turn cwd differs from `expectedCwd`; - the thread is not persistence-enabled. The cwd check must be part of the same reserved admission operation; checking it in app-server before submission would leave another race. Core now has most of the required primitive: [PR 38275](https://github.com/openai/codex/pull/38275) added ordered `CodexThread::start_turn_if_idle` / `TurnInputMode::StartIfIdle`. The remaining work is a small precondition extension plus the experimental app-server protocol/processor surface, schemas, docs, and focused fake-provider regressions. This does not require a new delivery queue, retry loop, fallback to `turn/start`, approval response, or replacement client. ### Additional information We ran into this while building a small resident app-server integration at @clevvi: inbound work should wake an idle Codex thread, but must leave an active TUI turn completely alone. Related, but not duplicates: - [#20312](https://github.com/openai/codex/issues/20312) asks for a broader native event-driven wake facility. - [#36866](https://github.com/openai/codex/issues/36866) documents the existing start-or-steer behavior and turn-ID consequences of `turn/start`. - [#34767](https://github.com/openai/codex/issues/34767) shows why multi-client admission needs a single authoritative turn boundary. I have a focused current-main patch and deterministic no-real-model tests in progress. Happy to open the PR if this API shape is welcome.", "url": "https://github.com/openai/codex/issues/38289", "createdAt": "2026-08-13T01:47:20Z", "updatedAt": "2026-08-13T01:47:53Z", "timestamp": "2026-08-13T01:47:53Z", "metrics": { "reactions": 0, "comments": 0 }, "labels": [ "enhancement", "CLI", "app-server" ], "author": "jrdeck", "state": "open", "assignees": [] }, { "id": "github:openai/codex:issue:38290", "source": "github", "group": "coding-agent-infrastructure", "project": "openai/codex", "kind": "issue", "title": "CreateProcess: Rejected(\"Failed to create unified exec process: helper_unknown_error: setup refresh had errors\")", "text": "### What version of the Codex App are you using (From “About Codex” dialog)? 26.803.81509 ### What subscription do you have? Plus ### What platform is your computer? Microsoft Windows NT 10.0.26200.0 x64 ### What issue are you seeing? Здравствуйте. В приложении Codex for Windows не работает выполнение команд в терминале для проекта D:\\Projects\\React\\BezVmyatin74. Любая команда, включая самые простые (Get-Location, dir, Get-Content), не запускается вообще. Ошибка возникает до выполнения PowerShell: CreateProcess: Rejected(\"Failed to create unified exec process: helper_unknown_error: setup refresh had errors\") Из-за этого агент не может прочитать файлы проекта, внести изменения, запустить lint/build или выполнить любую диагностику через терминал. Я уже перезапускал приложение и повторял проверку в новых задачах — результат тот же. Обычный PowerShell вне Codex стоит проверить отдельно, но по характеру ошибки проблема выглядит как сбой внутренней подготовки среды / sandbox Codex до запуска shell. Прошу подсказать, какие логи приложить и как восстановить работу терминала. ### What steps can reproduce the bug? В Codex for Windows не запускается встроенная среда выполнения команд в проекте. Шаги воспроизведения: 1. Открыть проект: D:\\Projects\\React\\BezVmyatin74. 2. Создать или открыть task в Codex. 3. Попросить агента выполнить любую терминальную команду, например: Get-Location или Get-Content -Raw src\\App.jsx Ожидаемый результат: Команда запускается в PowerShell, агент получает вывод и может читать/изменять файлы, запускать lint/build. Фактический результат: Команда не запускается до выполнения PowerShell. Для любой команды возвращается: CreateProcess: Rejected(\"Failed to create unified exec process: helper_unknown_error: setup refresh had errors\") Ошибка воспроизводится многократно, включая для минимальной команды Get-Location. Перезапуск приложения и новые task не помогли. Из-за этого агент не может прочитать исходники, выполнить правки или запустить проверки. Проект: D:\\Projects\\React\\BezVmyatin74 ОС: Windows Интегрированный shell: Windows PowerShell ID исходной задачи: 019ff37d-5b19-7bc2-a0cf-b141921935e0 Фрагмент для воспроизведения: Get-Location ### What is the expected behavior? Ожидается, что Codex создаст встроенный процесс терминала и выполнит команду в выбранном shell (Windows PowerShell). Например, после запуска команды `Get-Location` агент должен получить текущую рабочую папку проекта. После `Get-Content -Raw src\\App.jsx` он должен прочитать файл. Затем должны работать обычные команды разработки, включая lint и build. Терминальная среда должна запускаться для любой корректной команды и не должна завершаться ошибкой на внутреннем этапе setup refresh до запуска PowerShell. ### Additional information Проблема наблюдается внутри Codex Desktop на Windows и блокирует любую работу с локальным проектом: агент не может выполнить даже безопасную диагностическую команду, поэтому невозможно читать файлы, вносить изменения, запускать тесты, lint или build. Ошибка стабильно возникает до фактического запуска `powershell.exe`, поэтому это похоже на проблему подготовки внутренней среды выполнения / sandbox Codex, а не на ошибку конкретной команды или исходного кода проекта. Проверка выполнялась в проекте: D:\\Projects\\React\\BezVmyatin74 Буду признателен за указания, где найти и приложить диагностические логи приложения.", "url": "https://github.com/openai/codex/issues/38290", "createdAt": "2026-08-13T01:50:04Z", "updatedAt": "2026-08-13T01:51:23Z", "timestamp": "2026-08-13T01:51:23Z", "metrics": { "reactions": 0, "comments": 1 }, "labels": [ "bug", "windows-os", "sandbox", "tool-calls", "app" ], "author": "Color-maN", "state": "open", "assignees": [] }, { "id": "github:openai/codex:issue:38293", "source": "github", "group": "coding-agent-infrastructure", "project": "openai/codex", "kind": "issue", "title": "Windows computer control plugin cannot read windows and still returns EPERM after permission is granted — Environment: Windows, Codex desktop app", "text": "### What version of the Codex App are you using (From “About Codex” dialog)? 标题：Windows 电脑控制插件无法读取窗口，授权后仍返回 EPERM 环境： - Windows - Codex 桌面应用 - 电脑控制组件版本：26.803.81509 - 问题至少从 2026-08-12 持续至 2026-08-13 复现步骤： 1. 在 Codex 中请求使用电脑控制插件列出当前打开的窗口。 2. 插件调用 `sky.list_windows()`。 3. 运行立即失败，尚未读取到任何窗口。 错误信息： `EPERM: operation not permitted, lstat 'C:\\Users\\1\\AppData\\Local\\OpenAI\\Codex'` 补充诊断： - 已明确授予 `C:\\Users\\1\\AppData\\Local\\OpenAI\\Codex` 的读取权限。 - 授权后重置运行环境并再次调用，错误完全相同。 - 对该路径执行只读检查同样返回 `Access is denied`。 - 已多次重启 Codex，问题仍然存在。 - 插件没有切换、关闭或更改任何窗口。 预期结果： `sky.list_windows()` 应返回当前可控制窗口的列表，不应因 Codex 自身应用目录的访问权限而失败。 请重点检查 Windows 沙箱向电脑控制 Node 运行库传递文件系统权限的流程。 ### What subscription do you have? gpt plus ### What platform is your computer? Win11 ### What issue are you seeing? 标题：Windows 电脑控制插件无法读取窗口，授权后仍返回 EPERM 环境： - Windows - Codex 桌面应用 - 电脑控制组件版本：26.803.81509 - 问题至少从 2026-08-12 持续至 2026-08-13 复现步骤： 1. 在 Codex 中请求使用电脑控制插件列出当前打开的窗口。 2. 插件调用 `sky.list_windows()`。 3. 运行立即失败，尚未读取到任何窗口。 错误信息： `EPERM: operation not permitted, lstat 'C:\\Users\\1\\AppData\\Local\\OpenAI\\Codex'` 补充诊断： - 已明确授予 `C:\\Users\\1\\AppData\\Local\\OpenAI\\Codex` 的读取权限。 - 授权后重置运行环境并再次调用，错误完全相同。 - 对该路径执行只读检查同样返回 `Access is denied`。 - 已多次重启 Codex，问题仍然存在。 - 插件没有切换、关闭或更改任何窗口。 预期结果： `sky.list_windows()` 应返回当前可控制窗口的列表，不应因 Codex 自身应用目录的访问权限而失败。 请重点检查 Windows 沙箱向电脑控制 Node 运行库传递文件系统权限的流程。 ### What steps can reproduce the bug? 标题：Windows 电脑控制插件无法读取窗口，授权后仍返回 EPERM 环境： - Windows - Codex 桌面应用 - 电脑控制组件版本：26.803.81509 - 问题至少从 2026-08-12 持续至 2026-08-13 复现步骤： 1. 在 Codex 中请求使用电脑控制插件列出当前打开的窗口。 2. 插件调用 `sky.list_windows()`。 3. 运行立即失败，尚未读取到任何窗口。 错误信息： `EPERM: operation not permitted, lstat 'C:\\Users\\1\\AppData\\Local\\OpenAI\\Codex'` 补充诊断： - 已明确授予 `C:\\Users\\1\\AppData\\Local\\OpenAI\\Codex` 的读取权限。 - 授权后重置运行环境并再次调用，错误完全相同。 - 对该路径执行只读检查同样返回 `Access is denied`。 - 已多次重启 Codex，问题仍然存在。 - 插件没有切换、关闭或更改任何窗口。 预期结果： `sky.list_windows()` 应返回当前可控制窗口的列表，不应因 Codex 自身应用目录的访问权限而失败。 请重点检查 Windows 沙箱向电脑控制 Node 运行库传递文件系统权限的流程。 ### What is the expected behavior? 希望codex可以接管我的电脑 ### Additional information _No response_", "url": "https://github.com/openai/codex/issues/38293", "createdAt": "2026-08-13T01:57:13Z", "updatedAt": "2026-08-13T07:48:52Z", "timestamp": "2026-08-13T07:48:52Z", "metrics": { "reactions": 0, "comments": 3 }, "labels": [ "bug", "windows-os", "sandbox", "app", "computer-use" ], "author": "zouzhi27neverz", "state": "open", "assignees": [] }, { "id": "github:openai/codex:issue:38294", "source": "github", "group": "coding-agent-infrastructure", "project": "openai/codex", "kind": "issue", "title": "Codex credits consumed ~38,000–39,000 overnight with zero tasks issued — recurring bug, cap not enforced, no warning given", "text": "What happened: This has occurred twice, with nearly identical credit figures despite different credit caps each time. Incident 1 (last Thursday afternoon KST) Monthly credit cap: 5,000 Was actively working in the afternoon when Codex suddenly returned a \"limit exceeded\" error — with no prior low-credit warning Usage showed 38,140 credits consumed — over 7x the cap I did not receive any warning that credits were running low before being cut off Incident 2 (last night overnight KST) Monthly credit cap: 10,000 (raised by org after Incident 1) Last task completed at 01:02 KST, Codex last responded at 01:03 KST I went to sleep immediately after — zero tasks or commands issued after 01:03 KST Woke up at 10:14 KST to: \"You have reached the usage limit. Please contact your workspace owner for more access.\" 39,078 credits consumed in a ~9 hour window while I was asleep and issued zero tasks Why I believe this is a bug: Both incidents produced nearly identical totals (~38,000–39,000) even though caps were different (5,000 vs 10,000). Real usage cannot produce identical figures across different caps. Hard cap was exceeded by 7x (Incident 1) and 4x (Incident 2) — cap is clearly not being enforced. Incident 2 consumption occurred entirely while I was asleep with zero tasks, confirmed by timestamps. No low-credit warning was given before cutoff in either incident. /usage is blocked due to \"no credits remaining\" — making self-diagnosis impossible even as a read-only query. Environment: Client: VS Code Codex extension Timezone: KST (UTC+9) Subscription: Organization workspace (org-assigned credit limit) Expected behavior: Credit consumption should not occur without user-initiated tasks Hard cap should be enforced and not exceeded Low-credit warning should be issued before cutoff /usage should not be blocked when trying to diagnose a billing issue Additional context: This appears to be affecting multiple accounts within our organization. An internal company-wide notice has been issued regarding abnormal Codex credit consumption. A support ticket has already been filed (case on file with OpenAI Support). Similar issues reported by others: #26306 — abnormal quota consumption after reset community.openai.com: \"Codex credits are draining while idle\"", "url": "https://github.com/openai/codex/issues/38294", "createdAt": "2026-08-13T02:07:18Z", "updatedAt": "2026-08-13T02:08:44Z", "timestamp": "2026-08-13T02:08:44Z", "metrics": { "reactions": 0, "comments": 1 }, "labels": [ "bug", "extension", "rate-limits" ], "author": "chang-kr", "state": "open", "assignees": [] }, { "id": "github:openai/codex:issue:38295", "source": "github", "group": "coding-agent-infrastructure", "project": "openai/codex", "kind": "issue", "title": "Windows: all Claude-marketplace plugin hooks fail — hook bash resolves to the WSL shim; async hook protocol unsupported; failures report only 'Failed' with no diagnostics", "text": "## Environment - Codex CLI 0.144.1, 0.146.0, 0.147.0 (identical behavior on all three), npm install - Windows 11 Pro 10.0.26200 - Plugins from the `claude-plugins-official` marketplace: `security-guidance` 2.0.7, `superpowers` 6.3.0, `ralph-loop` 1.0.0 - WSL installed (Ubuntu default distro), Git for Windows installed ## Summary On Windows, every hook declared by Claude-marketplace plugins reports `Failed` on every fresh `codex exec` run — all four phases (`SessionStart`, `UserPromptSubmit`, `PostToolUse`, `Stop`). The root cause is that Codex resolves the hook interpreter `bash` via PATH. On a default Windows setup, PATH `bash` is the WindowsApps WSL shim (`%LOCALAPPDATA%\\Microsoft\\WindowsApps\\bash.exe`), and WSL bash cannot execute Windows-style script paths: ``` $ bash \"C:\\Users\\\\.codex\\plugins\\cache\\claude-plugins-official\\security-guidance\\2.0.7\\hooks\\sg-python.sh\" /bin/bash: C:UsersAJCam.codexpluginscacheclaude-plugins-officialsecurity-guidance2.0.7hookssg-python.sh: No such file or directory (exit 127) ``` Since effectively all Claude-marketplace plugin hooks are `bash