fix: say what Allow network access really opens (release review)

The setting told users the sandbox and approvals stay on. With it on, a
command in Codex's sandbox can call Codeman's API, which can start a session
outside the sandbox with no approval prompt. Measured on codex 0.162.0 with
`codex sandbox`: a touch the sandbox refused landed through POST /api/sessions,
and from inside a Codeman pane it landed with a password set too, because a
pane inherits CODEMAN_PASSWORD. Without that password the same call gets 401.

The settings row, the wiki, the skill and the changeset now say so, the wiki
Security page and security-architecture name it, and the docs scope the claims
to what the code does: app-wide, local launches only, not cron jobs, and
--no-daemon is a local launch's flag. Agent-CLIs gains the --no-daemon
trade-off. A test pins that no surface sells the sandbox as still in charge.

Text only: the switch, the clamp and the launch are unchanged.

Co-Authored-By: Claude Opus 5.5 <noreply@anthropic.com>

.changeset/codex-skill-network.md

@@ -2,4 +2,4 @@
 "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.
+**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 every new local Codex session with `sandbox_workspace_write.network_access=true`, so the skill's calls to this server are no longer blocked by Codex's sandbox. It has a cost: commands in Codex's sandbox can then call Codeman's API, which can start a session outside the sandbox with no approval prompt, even when a password is set, so the sandbox no longer contains a prompt-injected command. It is forced off for users without the privileged-commands grant in multi-user mode, and scheduled jobs do not use it. 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. A local Codex 0.162 or 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. Remote and Docker launches do not get the flag. 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.