[macOS][Desktop 26.818.21641] Chat creation/switching fails with opaque owned/promise error and app-server grows to ~10 GB RSS

Open 💬 4 comments Opened Aug 20, 2026 by zlwjjww
💡 Likely answer: A maintainer (github-actions[bot], contributor) responded on this thread — see the highlighted reply below.

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 (build 25G76)
  • 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:

  1. Launch Codex Desktop.
  2. Open or run a long multi-agent task.
  3. Continue working for several minutes.
  4. Send a follow-up message, switch tasks, or create a new task.
  5. The operation fails with the opaque JSON value above.
  6. 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-server reached 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/list requests 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_failed with the same serialized value
  • Received turn/started for unknown conversation
  • Received 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 ~/.codex state, the fact that reinstall did not help is consistent with a persisted session/index trigger.

View original on GitHub ↗

4 Comments

github-actions[bot] contributor · 8 days ago

Potential duplicates detected. Please review them and close your issue if it is a duplicate.

  • #39226
  • #39013
  • #39469

Powered by Codex Action

neilyoung · 5 days ago

My .codex got too fat. Removed the biggest parts. Error gone for now

o-henry · 4 days ago

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

{"value":{},"source":"owned","hooks":[],"promises":[]}

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 resume on a thread previously opened in Desktop can fail with thread ... 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.

radimirradev · 2 days ago

Last version of codex is total crap with this {"value":{},"source":"owned","hooks":[],"promises":[]} error. Its totally useless.