[Ark0N]

What this is about

Codeman injects its codeman agent skill into every agent CLI's workspace (agentSkillEnabled), so an agent can start worker sessions, prompt them, wait for them, read their output and delete them over Codeman's HTTP API. This PR makes that work from Codex, and records that OpenCode and DeepSeek Harness already work.

What I measured first (2026-11-01, prod 1.47.0)

For each CLI I started a throwaway session in a scratch case and gave it the same task: "use the codeman skill: spawn one shell worker, send it echo SKILLTEST-OK, read its output, delete the worker".

CLI	Result before this PR
DeepSeek Harness 0.1.1 (qwen on the 5090)	Works first try: spawned, sent, read SKILLTEST-OK, deleted, 35 s
OpenCode 1.3.0 (same model via OPENCODE_CONFIG_CONTENT)	Works first try, same steps
Codex 0.162.0	Broken, three separate ways (below)

Codex failures:

1. Shared app-server daemon. Codex 0.162 hands every client's commands to one background codex app-server --managed-daemon. On this machine a 0.166 daemon was running, so every new Codex pane stopped on an "Background server has incompatible feature settings" dialog before the composer appeared. Commands also run with the environment of whichever client started the daemon, so $CODEMAN_SESSION_ID / $CODEMAN_API_URL inside Codex belong to another session (the skill's self-check 404s and its self-delete guard protects the wrong id).
2. Sandbox blocks loopback. Every curl to 127.0.0.1:3000 failed with exit 7 / connect EPERM. The skill told the agent to stop and ask for Bypass approvals and sandbox, which removes the sandbox entirely.
3. codeman: command not found. The skill advertises codeman agent spawn as the one-command path, and on an install without the codeman link on PATH Codex gave up instead of using the skill's curl path.

Changes

• --no-daemon for Codex 0.162+ (registry data in the codex entry of stock.ts, behind a new noDaemonFlag version gate, fail-closed). Each Codex pane runs its own app server, which is what one pane per session means anyway. Older or unknown Codex versions get nothing, since an unknown flag makes Codex exit. Unconditional for Codex because the dialog breaks launches whether or not the skill is on.
• Version gates are measured against the gated CLI's own version. session-cli-registry-bridge.ts resolved every gate with getClaudeCliVersion(), because claude was the only CLI with a gate. A codex gate would have passed on any claude 2.x. It now uses the existing resolveSessionCliVersion(entry.id), which still routes claude to its own probe policy, so claude launches are unchanged. New test: test/cli-registry-gate-version.test.ts (both resolvers mocked to different versions).
• New opt-in setting: App Settings, Codex, "Allow network access" (codexNetworkAccess, synced, default OFF). Starts Codex with --config sandbox_workspace_write.network_access=true. It is a launchDefaults entry, so it reaches every local Codex launch (browser, skill quick-start, codeman agent spawn, MCP start_session), and a privilegedParams entry, so a non-granted owner in multi-user mode gets it forced off (the clamp runs after the defaults are filled; tested). Off keeps every launch byte-identical.
• Skill text (skills/codeman/SKILL.md, plugin mirror synced): codeman: command not found now says to carry on with the curl path; a blocked call says to re-run the same command once through the CLI's own approval path, then names the new setting, with bypass as the fallback; the daemon note says Codeman now prevents it.
• Docs: wiki Codeman-Skill.md (When the agent is Codex, plus a line that OpenCode and DeepSeek Harness need nothing extra), Settings-Reference.md, and the gates field in docs/cli-registry.md.

Verified after the change

On an isolated beta instance (CODEMAN_INSTANCE, own data dir and tmux socket, port 5293) built from this branch:

• Setting ON: POST /api/quick-start codex session launched as codex --no-daemon --config sandbox_workspace_write.network_access=true, session cliVersion probed from codex itself (0.162.0), no daemon dialog.
• Setting OFF: launched as codex --no-daemon, nothing filled into codexConfig, no daemon dialog.
• Codex in workspace-write (/status: "workspace with network access, Ask for approval"), with codeman removed from PATH as on a source-checkout install: Codex fell back to the curl preamble and created, prompted and deleted a shell worker with zero approval prompts.
• Codex in a folder it runs read-only (a fresh non-git case): the network stays closed, Codex asked to re-run the blocked command with approval, and after approval the whole spawn, send, wait, read, delete flow succeeded.
• Playwright against the beta: the switch renders in the Codex group, loads the saved value, and saving off and on round-trips through PUT /api/settings.
• npm run typecheck, npm run lint, npm run format:check, npm run check:frontend-syntax, and the full npm test gate.

Question for the owner

The network flag only applies where Codex runs the folder in its workspace-write sandbox, which Codex does for a project you trusted (its own "Auto" preset is workspace-write plus on-request approvals). In a folder Codex runs read-only, such as a new quick-start case that is not a git repository, Codex keeps the network closed and asks per command. Should "Allow network access" also pass --sandbox workspace-write so those scratch cases work without approvals? I recommend no: that also grants write access to a folder Codex itself chose not to trust, under a label that only says "network". The alternative is a separate, explicitly named setting.

Not in this PR

• On a machine where codeman is not on PATH (a server run from a source checkout without install.sh's ~/.local/bin/codeman link), codeman agent stays unavailable to pi and shell workers; the skill's curl path covers the other CLIs.