[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 (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.

Start with the bundled codex app-server and the repeated Desktop log messages for config requirements, pinned_thread_sync_failed, and unknown conversations. Reproduce the failure during a long-running task while monitoring app-server CPU/RSS, ~/.codex session growth, logs_2.sqlite, and thread/turns/list latency. Done should mean chat creation, switching, and sending remain reliable with bounded resource use and actionable errors.