Codex Desktop fails to surface a clear error when primary runtime install cannot write cache directory

What version of the Codex App are you using (From “About Codex” dialog)?

26.611.62324

What subscription do you have?

pro

What platform is your computer?

Darwin 24.5.0 arm64 arm

What issue are you seeing?

When the primary runtime cache directory is not writable, Codex Desktop does not surface a clear user-facing error. In my case, invoking the Chrome plugin appeared to interrupt/complete the turn without an actionable explanation, making it look like the plugin/tool call itself broke the session.

What steps can reproduce the bug?

1. Make the user cache directory unwritable or owned by another user, for example by having ~/.cache owned by root.
2. Launch Codex Desktop.
3. Ask Codex to use the Chrome plugin, for example to list currently open Chrome tabs.
4. Observe the conversation behavior and local logs.

What is the expected behavior?

Codex should surface an actionable user-facing diagnostic when primary runtime installation cannot create or write the runtime cache directory.

Examples:

• Tell the user that the runtime cache directory is not writable.
• Include the failing path.
• Suggest a safe remediation.
• codex doctor should detect this state before users hit opaque plugin failures.

Additional information

The user-visible behavior is confusing: the assistant turn appears to stop/complete without a clear plugin/runtime error or remediation.

Local logs contained:

• primary_runtime_install_failed: EACCES: permission denied, mkdir '～/.cache/codex-runtimes'
• primary_runtime_update_poll_failed: EACCES: permission denied, mkdir '～/.cache/codex-runtimes'
• Received turn/started for unknown conversation ...
• Received turn/completed for unknown conversation ...

The session record did not show an actual Chrome tool call in the initial failing turns, which made the failure look like a tool-routing/session issue rather than a cache permission problem.