Codex CLI is detected in setup but generation fails because Codex cannot access ~/.codex runtime state

[alchemistklk]

Summary

Open Design detects Codex CLI in the local agent setup screen and allows it to be selected, but generation is not actually usable from this environment because codex exec fails while creating its Codex session/runtime state.

This creates a confusing setup state: the UI reports Codex as installed/selectable, but the CLI cannot start a run.

UI evidence

In the setup screen at http://localhost:5173/:

• Local CLI reports 3 installed.
• Codex CLI is listed as installed with version codex-cli 0.125.0.
• Selecting Codex shows Codex-specific controls, including Reasoning effort.

So PATH/version detection works, but runtime execution does not.

Reproduction

From the repo:

cd /Users/alche/Documents/agentic-editor/open-design
which codex
codex --version
codex exec --cd /Users/alche/Documents/agentic-editor/open-design --skip-git-repo-check 'Reply with exactly: codex-ok'

Observed output:

/opt/homebrew/bin/codex
WARNING: proceeding, even though we could not update PATH: Operation not permitted (os error 1)
codex-cli 0.125.0
WARNING: proceeding, even though we could not update PATH: Operation not permitted (os error 1)
Reading additional input from stdin...
2026-04-29T08:49:27.075237Z ERROR codex_core_skills::manager: failed to install system skills: io error while remove existing system skills dir: Operation not permitted (os error 1)
2026-04-29T08:49:30.337336Z ERROR codex_models_manager::manager: failed to refresh available models: stream disconnected before completion: error sending request for url (https://chatgpt.com/backend-api/codex/models?client_version=0.125.0)
2026-04-29T08:49:30.357373Z ERROR codex_core::session: Failed to create session: Operation not permitted (os error 1)
Error: thread/start: thread/start failed: error creating thread: Fatal error: Codex cannot access session files at /Users/alche/.codex/sessions (permission denied). If sessions were created using sudo, fix ownership: sudo chown -R $(whoami) /Users/alche/.codex (underlying error: Operation not permitted (os error 1))

What the app currently does

Detection appears to be based on PATH/version probing in daemon/agents.js. Since codex --version succeeds, the app marks Codex as available.

Generation later calls the adapter from daemon/server.js, which spawns something equivalent to codex exec .... That call can fail because Codex needs access to ~/.codex/sessions and system skill/runtime state.

Expected behavior

Open Design should distinguish:

1. CLI binary found on PATH.
2. CLI can actually start a non-interactive run from the daemon environment.

If runtime probing fails, the UI should show Codex as installed but not currently usable, with the stderr reason or a concise remediation hint.

Suggested fix

Add a deeper health check for Codex during agent detection or before first generation, for example:

codex exec --skip-git-repo-check --ephemeral 'health check'

or another cheap command that verifies Codex can create/start a session from the daemon process environment.

Then expose a state like:

• installed: true
• available: false
• reason: Cannot access ~/.codex/sessions from this process

This would prevent the current mismatch where Codex is selectable even though generation cannot start.

Environment

• Open Design local app: http://localhost:5173/
• Repo: nexu-io/open-design
• Codex CLI path: /opt/homebrew/bin/codex
• Codex CLI version: codex-cli 0.125.0
• macOS local environment

[lefarcen]

Hi @alchemistklk! 👀

Thanks for opening this issue — excellent analysis of the Codex CLI detection vs. runtime availability gap.

You're absolutely right that we need a deeper health check beyond just PATH/version probing. The current setup creates a confusing state where Codex appears selectable but cannot actually start runs due to session file access issues.

Questions to help us fix this:

1. Does the permission error happen consistently, or only in certain environments (e.g., when the daemon runs under a different user)?
2. Would you be interested in contributing a PR for the deeper health check you suggested? The codex exec --ephemeral 'health check' approach looks solid.

We'll investigate the daemon environment and permission model. Your suggested fix of exposing installed: true + available: false + reason is exactly the right direction.

Join our community while you're here:

• Feishu: https://applink.feishu.cn/client/chat/chatter/add_by_link?link_token=90emc2e9-86cd-4723-b455-ca41b70f162d
• Discord: https://discord.gg/nexu

Thanks for making open-design better!
— open-design team