[macOS][Desktop 26.818.21641] Chat creation/switching fails with opaque owned/promise error and app-server grows to ~10 GB RSS
cc @tibo-openai
What version of the Codex App are you using?
- Codex Desktop for macOS:
26.818.21641 - Bundled Codex CLI:
0.148.0-alpha.21
What platform is your computer?
- macOS
26.6.1(build25G76) - Apple Silicon Mac
- 48 GB RAM
What issue are you seeing?
After Codex Desktop has been running for a few minutes, sending a message, switching tasks, or creating a new task can fail. The UI shows a red “Error creating chat” toast containing an internal-looking serialized value:
{"value":{},"source":"owned","hooks":[],"promises":[]}
Restarting the app restores functionality temporarily, but the failure returns. Reinstalling the app and archiving the large task did not resolve it.
This appears to be the macOS/cross-platform variant of #39226, with additional evidence of severe resource growth and very large persisted task history. It may also be related to the unknown-conversation routing symptoms in #21167.
Steps to reproduce
The precise trigger timing is intermittent, but the observed sequence is:
- Launch Codex Desktop.
- Open or run a long multi-agent task.
- Continue working for several minutes.
- Send a follow-up message, switch tasks, or create a new task.
- The operation fails with the opaque JSON value above.
- Quit and reopen Codex; it works temporarily and then fails again.
Archiving the task does not prevent recurrence.
Expected behavior
- Sending, switching, and creating tasks should remain reliable during long-running sessions.
- Archived tasks should not continue causing foreground task-loading failures.
- Background CPU and memory use should remain bounded.
- Errors should be actionable instead of exposing an internal promise/ownership object.
Diagnostics
Sanitized local observations:
- The bundled
codex app-serverreached approximately 98–102% CPU and 9.7–10.0 GB RSS about three minutes after launch. ~/.codex/sessions: approximately 5.6 GB across 304 files.- Largest active rollout: approximately 3.45 GB.
~/.codex/archived_sessions: approximately 54 GB across 2,752 files.~/.codex/logs_2.sqlite: approximately 1.6 GB.- Repeated
thread/turns/listrequests for the large task took approximately 8–12 seconds. - Desktop logs repeatedly contained:
Failed to load config requirements error={"value":{},"source":"owned","hooks":[],"promises":[]}pinned_thread_sync_failedwith the same serialized valueReceived turn/started for unknown conversationReceived turn/completed for unknown conversation
Relevant feature configuration:
# ~/.codex/config.toml
[features]
multi_agent_v2 = true
# project .codex/config.toml
[features]
multi_agent = true
hooks = false
The bundled CLI recognizes both multi_agent and multi_agent_v2 as valid stable feature flags, so this does not look like a TOML syntax error. I cannot confirm that v2 is the sole cause; it may instead expose or amplify transcript/index growth or conversation-registry inconsistency.
Additional information
- No source code, full logs, task titles, thread IDs, credentials, or unredacted local paths are included.
- The original error screenshot and narrowly sanitized log excerpts can be supplied privately if useful.
- Since reinstalling the app does not clear the persisted
~/.codexstate, the fact that reinstall did not help is consistent with a persisted session/index trigger.
4 Comments
Potential duplicates detected. Please review them and close your issue if it is a duplicate.
Powered by Codex Action
My .codex got too fat. Removed the biggest parts. Error gone for now
Another reproducible macOS case. Codex Desktop becomes effectively unusable after the composer/session failure starts: sending a prompt, creating a new chat/task, or switching threads can fail with the raw object
This is not an isolated machine-specific issue; the same error has also been reported by other users outside GitHub. Restarting the app may temporarily recover it, but the failure can recur.
Impact is severe because the obvious fallback to CLI is also impaired by the separate writer-ownership regression:
codex resumeon a thread previously opened in Desktop can fail withthread ... already has an active writer (code -32600)until the Desktop process is fully terminated.Please treat this as a workflow-blocking regression rather than a cosmetic UI issue. It would be very helpful to have: (1) confirmation that the issue is actively tracked, (2) the affected build range, (3) a known-safe workaround or rollback build, and (4) the target build/ETA for a fix.
Last version of codex is total crap with this {"value":{},"source":"owned","hooks":[],"promises":[]} error. Its totally useless.