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>

docs/wiki/Agent-CLIs.md

@@ -143,10 +143,21 @@ Changing a default affects new sessions and does not edit Codex configuration fi
 **Allow network access** reaches the same local launches. It opens the network only where
 Codex runs the folder in its workspace-write sandbox and does not change Codex's sandbox
 mode: a folder Codex runs read-only keeps the network closed, and Codex asks per command.
-See [The Codeman Skill](Codeman-Skill#when-the-agent-is-codex).
+With it on, commands in the sandbox can call Codeman's API, which can start a session
+outside the sandbox with no approval prompt, even when a password is set. See
+[The Codeman Skill](Codeman-Skill#when-the-agent-is-codex) and
+[Security](Security#what-codeman-does-not-protect-against).
 
-Two behaviours that are deliberate and worth knowing:
+Behaviours that are deliberate and worth knowing:
 
+- **Each local session runs its own app server.** Codex 0.162 and later otherwise hands
+  every client's commands to one shared background server, which runs them with the
+  environment of whichever session started it, and a server left by another Codex version
+  stops every launch on a dialog. So Codeman starts a local Codex 0.162 or later with
+  `--no-daemon`. The trade-off, going by Codex's own help text: `codex agents` browses the
+  sessions on that shared server and `codex remote-control` manages it, so do not expect
+  either to see a session started this way. Remote and Docker launches do not get the
+  flag, and neither does a local launch whose Codex version Codeman could not read.
 - **Predictive echo instead of buffered echo.** Codex's composer reacts to every keystroke,
   a `/` opens a live-filtering picker, arrows edit server-side state. Buffering keystrokes
   until Enter starved it, so Codex paints each keystroke at the predicted cell while the

docs/wiki/Codeman-Skill.md

@@ -140,20 +140,25 @@ message a worker directly instead of typing into its terminal.
 
 Two things to know:
 
-- Codex's default sandbox blocks network access, even to this machine, so turn on
-  **Allow network access** (App Settings, Codex) for a Codex session that should start and
-  drive others. It applies to Codex sessions started after you switch it on, and it keeps
-  Codex's sandbox and approval prompts. It opens the network only where Codex runs the
-  folder in its workspace-write sandbox, which is what Codex does for a project you
-  trusted. It does not change Codex's sandbox mode: a folder Codex runs read-only (a new
-  case that is not a git repository, for one) keeps the network closed, and Codex asks you
-  to approve each call to Codeman. Trust the project in Codex, or use `/permissions` in
+- Codex's default sandbox blocks network access, even to this machine, so a Codex session
+  needs **Allow network access** (App Settings, Codex) before it can start and drive
+  others. The setting is app-wide: it applies to every local Codex session started after
+  you switch it on, not only the ones you mean to orchestrate. It also 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. See
+  [Security](Security#what-codeman-does-not-protect-against). It opens the network only
+  where Codex runs the folder in its workspace-write sandbox, which is what Codex does for
+  a project you trusted. It does not change Codex's sandbox mode: a folder Codex runs
+  read-only (a new case that is not a git repository, for one) keeps the network closed,
+  and Codex asks you to approve each call to Codeman. Trust the project in Codex, or use `/permissions` in
   Codex for that session, to get workspace-write there. **Bypass approvals and sandbox**
   works everywhere, but removes the sandbox and the approval prompts.
 - Codex 0.162 runs its commands in a shared background process, whose Codeman variables can
-  belong to the session that started it. Codeman starts Codex 0.162 and later with
-  `--no-daemon`, so each session runs its own; with an older Codex the skill notices and
-  says so instead of acting.
+  belong to the session that started it. Codeman starts a local Codex 0.162 or later with
+  `--no-daemon`, so each session runs its own. A remote or Docker session does not get the
+  flag, and neither does a local one whose Codex version Codeman could not read; there,
+  and with an older Codex, the skill notices and says so instead of acting.
 
 OpenCode and DeepSeek Harness need nothing extra: in their default setup neither keeps its
 shell commands off the network, so the skill works there as soon as it is injected.

docs/wiki/Security.md

@@ -99,6 +99,12 @@ Stated plainly, because a security page that only lists strengths is not useful:
   bypass requires a secret unconditionally when auth is on.
 - **The agent CLIs have their own trust models.** Pi's project trust executes repo-local
   TypeScript, for instance. See [Agent CLIs](Agent-CLIs).
+- **Allow network access takes Codex's sandbox out of the picture.** The setting (App
+  Settings, Codex, off by default) lets commands in Codex's sandbox call Codeman's API,
+  which can start a session outside the sandbox with no approval prompt. A password does
+  not stop this, because a session inherits the server's password. It applies to every new
+  local Codex session, so a prompt-injected command in any of them can run anything you
+  can. Leave it off unless you trust what those sessions run.
 
 ## Privacy
 

docs/wiki/Settings-Reference.md

@@ -208,7 +208,7 @@ instead of its native cloud backend. See [Custom Model Endpoints](Custom-Model-E
 | Default Codex model              | Model for new local Codex sessions; empty uses Codex's own config. Letters, digits, `.` `_` `-` `/` only. |
 | Default Codex reasoning effort   | Reasoning level for new local Codex sessions; empty uses Codex's own config.                   |
 | Bypass approvals and sandbox     | Starts new Codex sessions with `--dangerously-bypass-approvals-and-sandbox`. Read [Agent CLIs](Agent-CLIs) before enabling. |
-| Allow network access             | Starts new local Codex sessions with `sandbox_workspace_write.network_access=true`, so commands in Codex's workspace-write sandbox can use the network. The [Codeman Skill](Codeman-Skill) needs it to reach this server from a Codex session. It applies where Codex runs the folder in workspace-write (a project you trusted in Codex) and does not change Codex's sandbox mode: a folder Codex runs read-only keeps the network closed, and Codex asks for approval per command. The sandbox and approval prompts stay on. Synced, off by default; forced off for users without the privileged-commands grant in multi-user mode. |
+| Allow network access             | Starts new local Codex sessions (Run menu, Resume and the API; not scheduled jobs) with `sandbox_workspace_write.network_access=true`, so commands in Codex's workspace-write sandbox can use the network. The [Codeman Skill](Codeman-Skill) needs it to reach this server from a Codex session. It applies to every such session, and those commands can then call Codeman's API, which can start a session outside the sandbox with no approval prompt, even when a password is set: see [Security](Security#what-codeman-does-not-protect-against). It applies where Codex runs the folder in workspace-write (a project you trusted in Codex) and does not change Codex's sandbox mode: a folder Codex runs read-only keeps the network closed, and Codex asks for approval per command. Synced, off by default; forced off for users without the privileged-commands grant in multi-user mode. |
 | Animated status effects          | Cosmetic.                                                                                      |
 | MCP server sync                  | Copies the MCP servers each installed, enabled CLI (Claude, Codex, Gemini, OpenCode, Antigravity) and GitHub Copilot CLI has into the others' own config files. Synced, off by default, admin only in multi-user mode. Turn it on and **Apply** or **Save** (Apply keeps Settings open), then **Preview** shows what would change and **Sync now** applies it. It only adds missing servers, keeps the previous file as `.codeman-bak`, and leaves a file that receives env values or headers readable by you only. A config dir moved by `CODEX_HOME`, `CLAUDE_CONFIG_DIR`, `XDG_CONFIG_HOME`, `GEMINI_CLI_HOME` or `COPILOT_HOME` in Codeman's own environment is followed. |