Codeman maintainer
131a12d195
The owner's answer to the PR's open question: the switch does not also pass --sandbox workspace-write. Settings, wiki, skill and release note now state the consequence: a folder Codex runs read-only keeps the network closed and asks per command. A golden test pins the decision by name, and the stale launch-defaults comments now name networkAccess. Co-Authored-By: Claude Opus 5.5 <noreply@anthropic.com>
1.2 KiB
aicodeman
| aicodeman |
|---|
| minor |
Codex sessions can drive other sessions through the Codeman skill. A new opt-in Codex setting, Allow network access (App Settings, Codex, off by default), starts Codex with sandbox_workspace_write.network_access=true, so the skill's calls to this server are no longer blocked by Codex's sandbox; the sandbox and approval prompts stay on, and it is forced off for users without the privileged-commands grant in multi-user mode. It applies where Codex runs the folder workspace-write and does not change Codex's sandbox mode: a folder Codex runs read-only keeps the network closed and asks per command. Codex 0.162 and later now also starts with --no-daemon, so each session runs its own Codex app server: a shared background server (another version's included) no longer stops a launch on an "incompatible feature settings" dialog, and commands inside Codex see their own session's CODEMAN_* variables. Version gates in the CLI registry are now measured against that CLI's own version instead of Claude's. The skill falls back to its curl path when codeman is not on PATH, and asks Codex to re-run a blocked call with approval instead of giving up.