@prohost/cli 0.2.1 → 0.2.3

package/CHANGELOG.md

@@ -4,6 +4,217 @@ Versions follow [semver](https://semver.org/). Publishing is automated: merging
 a version bump to `main` triggers `.github/workflows/npm-publish-cli.yml`, which
 builds via `prepack`, runs the suite, publishes, and tags `cli-v<version>`.
 
+## 0.2.3
+
+Three things, all of them about a run knowing what is actually true about
+itself: a prompt bullet that taught agents to doubt tools they had, a way to
+give an agent a tool on purpose, and closing the gaps 0.2.2 shipped with an
+honest note attached.
+
+- **A ToolSearch miss no longer reads as proof.** 0.2.1 told the agent to
+  "search ToolSearch for a capability before telling anyone you lack it", which
+  is right about deferred web browsing and badly wrong as a general rule. In
+  production a paired brain searched ToolSearch for `bash`, found nothing —
+  ToolSearch indexes only the *deferred* tools, and Bash is a direct one — and
+  spent an entire resumed session reporting it had no shell, while
+  `--dangerously-skip-permissions` had been handing it the full toolset the
+  whole time. The prompt now states that the directly-listed tools are the
+  authoritative set, that a ToolSearch miss is evidence of nothing, and that
+  "looking" means running the command rather than reading one's own tool list:
+  a claim of no shell, no file access or no checkout has to come after an
+  attempt that failed and can be quoted. The original bullet stays — deferred
+  browsing is real, and dropping it would just swap one wrong inference for the
+  other.
+- **`~/.prohost/extra-mcp.json` — opt-in extra MCP servers.** A run gets the
+  ProhostAI server and nothing else, and that isolation is a security boundary:
+  a run executes with permission prompts off on prompt text written by whoever
+  mentioned the agent. This adds a way to widen it deliberately without weakening
+  the default. Write the file yourself — the CLI never creates it — holding the
+  same `{"mcpServers": {…}}` object Claude Code's `--mcp-config` takes; it works
+  on both brains. The name `prohost` is reserved and an entry using it is
+  rejected out loud rather than silently honoured; a malformed file is a warning
+  and a run without extras rather than a run that doesn't happen; and which
+  servers loaded is printed when the grant set changes so `agent.log` can answer "did my server
+  load". Every server in that file is exercisable by anyone who can trigger the
+  agent, which the README, the file's own documentation and `--help` all say in
+  those words.
+- **Codex gets the isolation Claude Code has.** 0.2.2 shipped with "there is no
+  Codex equivalent of `--strict-mcp-config`", which turned out to be true of the
+  two mechanisms that look like one and false overall. `-c mcp_servers={…}` does
+  not replace the table — Codex deep-merges overrides — and `--ignore-user-config`
+  works but discards the operator's model, profile and sandbox settings along
+  with their servers. The one that works is per-server: the CLI now asks the
+  binary what it has (`codex mcp list --json`) and passes a single
+  `-c mcp_servers={"<name>"={enabled=false}, …}`, verified end to end against
+  `codex-cli 0.144.1` — the tools are genuinely gone from the model's list
+  mid-run, each server's own definition survives, and servers not named are
+  untouched. Asking the binary rather than parsing `~/.codex/config.toml`
+  matters twice over: on a normal install `codex mcp list` reports servers that
+  appear nowhere in that file, and the name has to go inside the value because
+  a server called `fly.io` written as `-c mcp_servers.fly.io.enabled=false`
+  addresses a three-segment path and makes Codex reject the entire config. The
+  override is also **verified against the binary before it is used**, which one
+  case genuinely needs: `{enabled=false}` merges onto a server's existing
+  definition, and a plugin-contributed server has none to merge onto, so the
+  override leaves a table with no transport and Codex refuses to start —
+  shipped unverified that would have broken every run for anyone with a Codex
+  plugin installed. The CLI falls back to checking each server on its own and
+  fails the run before Codex starts if any cannot be disabled. If the
+  enumeration fails outright the run also fails closed instead of proceeding
+  under `--yolo` with an unprovable boundary. Same treatment for `extra-mcp.json` definitions:
+  rejected ones are dropped with a warning rather than taking the run with them.
+  Every probe now runs in the exact cwd of the eventual Codex process as well,
+  so a trusted repo's project-local `.codex/config.toml` cannot appear only
+  after a clean-directory survey. Default `$PROHOST_HOME/workspace` and an
+  explicit harness `--workdir` both use that same path end to end.
+
+  Three further things the binary had to be asked rather than assumed. Every
+  server goes in **one** `-c mcp_servers={…}`, ProhostAI included: `-c`
+  overrides apply in order and a later whole-table assignment *replaces* an
+  earlier dotted one, so the obvious two-override shape silently dropped the
+  ProhostAI server on every run that disabled anything. An extra whose name
+  your Codex config already uses is **refused**, because Codex merges the two
+  definitions and the existing server's `Authorization` header would be sent to
+  the extra's URL. The extras file and Codex survey are refreshed before every
+  run, so deleting a grant or installing a new server takes effect immediately
+  in a long-lived daemon. Literal header and stdio environment secrets from the
+  Claude-shaped extras file are moved into Codex's child environment instead of
+  being exposed in process arguments.
+
+  One gap stays open and is documented rather than papered over: a `--exec`
+  running Codex under a named profile (`-p work`) can have MCP servers defined
+  only in `work.config.toml`, and `codex mcp list` cannot be asked about a
+  profile at all — `-p`/`--profile` are rejected and `-c profile="…"` is refused
+  as a removed legacy form. The CLI now fails the run before spawning Codex
+  when it sees a profile flag, including clap's joined `-pwork` spelling. It
+  also fails closed on `-c` / `--config`, feature toggles,
+  `--ignore-user-config`, and cwd-changing `-C` / `--cd` flags, because those
+  can make the real run's plugin/MCP inventory differ from the plain verifier
+  command. Finally, an
+  unrecognised item inside otherwise-valid `mcp list --json` output now makes
+  the entire survey unknown instead of being silently mistaken for no server.
+  Recognisable Codex commands containing shell quoting, expansion, glob,
+  comment or control syntax now fail before spawn instead of falling through to
+  the unshaped path; in particular, quoting an inventory-changing flag cannot
+  hide it from the verifier. The final probe must also report the ProhostAI
+  server and every accepted extra enabled — a successful empty or partial list
+  is no longer accepted as proof. Finally, all environment names referenced by
+  every extra are reserved before literal-header secret variables are
+  allocated, preventing one extra from naming and reading another extra's
+  generated credential, including through differently-cased aliases on Windows.
+  Ordinary unquoted Windows executable and workspace paths remain accepted by
+  the shell-syntax guard while `cmd.exe` expansion and control syntax still
+  fail closed.
+- **Codex reports refused tools.** Also filed under "no equivalent" in 0.2.2.
+  Codex has no `permission_denials` field, but a refused call arrives as an
+  `mcp_tool_call` item with `status: "failed"` and `user cancelled MCP tool
+  call`, which is what every run with nobody at the terminal produces. Those are
+  now printed on the same line the Claude Code path uses. A call that failed for
+  another reason — a server returning 502 — is deliberately not counted, so the
+  log doesn't send you to your permissions over a network problem.
+- **Codex is told how it spells its own tools.** The prompt used to name the MCP
+  server and leave the prefix out, because guessing a tool name is the same
+  failure as guessing an endpoint. Measured against the real binary by
+  registering a stub server and asking the model what it had just called: Codex
+  uses the same `mcp__<server>__<tool>` convention as Claude Code, so both
+  brains now get the pattern.
+
+## 0.2.2
+
+Two agents paired to the same workspace behaved like different products: the
+one on Claude Code remembered its threads and could look things up, the one on
+Codex ran bare. And neither knew who its operator had hired it to be — the
+persona configured in the ProhostAI agent profile never left the server.
+
+- **Your agent gets its soul.** `agent.run_requested` may now carry
+  `system_prompt` — the standing instructions written in the agent's ProhostAI
+  profile — and `agent_title`. The instructions render at the very top of the
+  prompt, above memories and history, fenced off from the server-generated
+  sections so the agent can always tell where its operator stops talking. The
+  title renders alongside the name: `You are "Ada" (Guest Experience Lead)`. The
+  fence is followed by a line stating that what comes after is generated for
+  this run and describes what is actually true about it — a soul configures the
+  agent, it does not get to talk it out of reporting a lookup it never made.
+  Both fields are optional in both directions, so an older server behaves
+  exactly as before.
+- **Attachments are visible.** `recent_messages[].attachments` and
+  `trigger_attachments` render as `[attached image "boiler.jpg": <url>]` inline
+  in the thread and as a list under the triggering message. An image-only
+  message — a guest who sends a photo of a broken boiler and nothing else —
+  used to be dropped entirely by the parser for having no text; it now survives
+  as the attachment it is, and the prompt says so rather than reporting the text
+  as missing. The agent is told plainly that a URL is not something it can see,
+  and to download one to a local file before opening it, because vision works on
+  local files and not on links.
+- **The agent stops claiming it has no access to your machine.** A brain
+  running unsandboxed on a laptop that holds the checkout, the credentials and
+  the CLI was still answering "I don't have access to the codebase". Ungated
+  runs are now told they are on the operator's own machine, in their shell, and
+  to take a *quick* look — usual checkout locations, `gh auth status`, whether
+  the command is on PATH — before declaring a capability missing. A quick look,
+  not an audit: the run has a hard time cap. Under `--safe-tools` the licence is
+  withheld, because there the looking would itself sit waiting on an approval
+  nobody is there to give.
+- **Codex gets the harness Claude Code has had since 0.2.0.** A `--exec` of
+  `codex exec` is now detected and shaped, with the same `--safe-tools` opt-out:
+
+  | | Claude Code | Codex |
+  |---|---|---|
+  | Structured output | `--output-format json` | `--json` (JSONL) |
+  | Session continuity | `--resume <id>` | `codex exec resume <thread>` |
+  | Tools | `--mcp-config` + `--strict-mcp-config` | `-c mcp_servers.prohost={…}` |
+  | Credential | `X-API-Key` in a `0600` file | `X-API-Key` via `env_http_headers` |
+  | Ungated by default | `--dangerously-skip-permissions` | `--yolo` |
+
+  Three things worth knowing about the Codex path. `--skip-git-repo-check` is
+  passed unconditionally, because the harness workspace is not a git repository
+  and Codex otherwise exits before the model is ever reached. `--yolo` is a
+  hidden alias of `--dangerously-bypass-approvals-and-sandbox` and passing both
+  spellings is a hard argument error, so a host who already wrote either one
+  never gets a second. And `resume` is appended *after* the host's own flags,
+  since `codex exec resume` accepts a strict subset of `codex exec`'s — a flag
+  that is legal before `resume` is rejected after it. When a resume is rejected
+  anyway, the run falls back to a fresh thread instead of failing the surface.
+- **`--safe-tools` now removes a bypass you wrote yourself.** It used to only
+  decline to *add* one, so `--exec 'codex exec - --yolo' --safe-tools` ran fully
+  unsandboxed while the harness logged "tools are permission-gated" and the
+  prompt told the agent approvals would stop it. Since this README recommended
+  exactly that `--exec` until now, the flag is sitting in existing installs. A
+  safety switch that quietly does nothing is worse than not having one, so both
+  `--yolo` / `--dangerously-bypass-approvals-and-sandbox` (Codex) and
+  `--dangerously-skip-permissions` (Claude Code) are now stripped when
+  `--safe-tools` is passed. Note this covers the full bypass only —
+  `--full-auto` still auto-approves inside Codex's sandbox.
+- **A Codex command carrying its own prompt is left alone.** `codex exec 'Be
+  terse'` keeps the plain stdin/stdout contract: Codex takes exactly one prompt
+  positional, so the `-` this harness appends would be a second one and the run
+  would fail outright with `unexpected argument '-'`. Standing instructions
+  belong in the agent's ProhostAI profile now, which is where `system_prompt`
+  comes from.
+- **The Codex credential never touches the command line.** Codex can read an
+  MCP header out of the environment (`env_http_headers`), so the API key is
+  passed to the child that way rather than inside the `-c` override. A command
+  line is world-readable out of `ps`; a process environment is not. This makes
+  the Codex path slightly *safer* than the Claude one, which still has to keep
+  the key in a `0600` file on disk.
+
+**Residual gaps on the Codex path**, both stated at start-up or in the prompt
+rather than papered over:
+
+- **No `--strict-mcp-config` equivalent.** Codex's `--ignore-user-config` was
+  the obvious candidate and does not work: it drops the `-c` overrides along
+  with the user config, taking the ProhostAI server with it. So a Codex run also
+  holds whatever MCP servers `~/.codex/config.toml` defines, with approvals
+  bypassed. The harness prints this at start-up rather than leaving an operator
+  to assume the Claude Code isolation applies.
+- **Codex's MCP tool naming is unverified**, so the prompt names the server
+  (`registered as "prohost"`) instead of asserting a `mcp__prohost__*` pattern
+  it has not confirmed. The agent can read its own tool list; a wrong tool name
+  is the same failure as a wrong endpoint.
+- **No permission-denial reporting.** Claude Code returns `permission_denials`
+  and the harness prints them; Codex's event stream has no equivalent, so a
+  refused tool stays as invisible on that path as it was before 0.2.0.
+
 ## 0.2.1
 
 - Prompt: tell brains with a ToolSearch tool that part of their toolkit

package/README.md

@@ -87,7 +87,7 @@ in a team thread, a 1:1 DM, a task comment, a trigger — you'll see:
 Other agents, same command:
 
 ```bash
-npx @prohost/cli agent run --exec 'codex exec - --yolo'
+npx @prohost/cli agent run --exec 'codex exec'
 npx @prohost/cli agent run --exec 'goose run -i -'
 npx @prohost/cli agent run --exec './my-agent.sh'
 ```
@@ -109,13 +109,14 @@ nothing is posted and the run is left open.
 2. The CLI verifies the event's HMAC signature. An event that doesn't verify is
    **not executed** — the whole point of the signature is that a run event makes
    your machine execute a command.
-3. It builds a prompt — who your agent is, what it's replying to, the recent
-   messages in the thread, anything the account remembers that bears on it, and
-   the message that mentioned it — and runs your `--exec` command with that
-   prompt on **stdin**.
+3. It builds a prompt — who your agent is, the standing instructions you wrote
+   in its ProhostAI profile, what it's replying to, the recent messages in the
+   thread, anything the account remembers that bears on it, and the message that
+   mentioned it — and runs your `--exec` command with that prompt on **stdin**.
+   Images and files on those messages appear as URLs the agent can download.
 4. Your command's **stdout** is the reply. It's posted into the conversation
    verbatim, so print the message and nothing else — no preamble, no reasoning.
-   (Claude Code is the exception: see below.)
+   (Claude Code and Codex are the exceptions: see below.)
 5. The run is completed either way. A command that crashes, times out, or prints
    nothing reports `failed`; a run is never left hanging.
 
@@ -135,8 +136,9 @@ directory. Just choose it deliberately.
 ### If your agent is Claude Code
 
 When `--exec` starts with `claude` and asks for print mode (`-p` / `--print`),
-the CLI does three extra things. Every other command — Codex, goose, your own
-script — is left exactly alone.
+the CLI does three extra things. Codex gets the same three through its own
+flags — see "If your agent is Codex" below. Every other command — goose, your
+own script — is left exactly alone.
 
 **It keeps the conversation.** Each run is a fresh process, so without this your
 agent meets every message as its first: someone answers its clarifying question
@@ -177,6 +179,180 @@ word of the command *and* print mode is asked for. Anything else — `npx claude
 redirect, or `&&` — keeps the plain stdin/stdout contract untouched. So
 `--exec 'sh -c "claude -p"'` is the way to opt out.
 
+### Giving the agent other MCP servers
+
+One server by default is a boundary, not an oversight: a run executes with
+permission prompts off, on prompt text written by whoever mentioned your agent.
+Every MCP server reachable from that run is a server your workspace teammates
+can drive.
+
+If you want to widen it anyway, create `~/.prohost/extra-mcp.json` by hand. The
+CLI never creates this file — its existence is you saying yes on purpose. The
+shape is the same `mcpServers` object Claude Code's `--mcp-config` takes, so you
+can lift a block straight out of an existing `.mcp.json`:
+
+```json
+{
+  "mcpServers": {
+    "linear": {
+      "type": "http",
+      "url": "https://mcp.linear.app/mcp",
+      "headers": { "Authorization": "Bearer lin_api_…" }
+    },
+    "notes": {
+      "command": "npx",
+      "args": ["-y", "@modelcontextprotocol/server-filesystem", "/Users/me/notes"]
+    }
+  }
+}
+```
+
+**Read this before you use it.** Every server in that file is exercisable by
+anyone who can trigger your agent — a teammate, a guest whose message routes to
+it — with permission prompts off and no human in the loop. A filesystem server
+scoped at `/` is a filesystem server they can read. Scope each one as narrowly
+as it will go.
+
+Works on both Claude Code and Codex. Details:
+
+- The name `prohost` is **reserved**. An entry using it is rejected with a line
+  in the log and the ProhostAI server stays pointed where pairing put it.
+- **On Codex, a name your own config already uses is also rejected.** Codex
+  merges the two definitions rather than replacing one with the other, so an
+  extra that changes only the URL would inherit the configured server's headers
+  and send its credential to the new host. Rename the extra to use it.
+- Malformed JSON costs you the extras, not the run: the CLI warns and starts
+  without them. The same is true of an entry whose value isn't an object.
+- The file is re-read before every run. Deleting an entry revokes it for the
+  next invocation of an already-running daemon; no restart is required.
+- Which extras loaded is printed when the grant set changes, so `agent.log` answers "did my
+  server actually load" without guessing.
+- On Codex the non-secret parts of each definition become `-c` overrides, which
+  means URLs, commands, and arguments land on a command line other users can
+  read via `ps`. Literal `headers`, `http_headers`, and stdio `env` values are
+  moved to the child environment instead. On Claude Code the definitions go
+  into `~/.prohost/mcp.json`, which is `chmod 600`.
+- Also on Codex: a value with something TOML can't express (an infinity, say)
+  makes that server skipped with a warning, rather than emitted as an override
+  that would fail to parse and take the ProhostAI server down with it. Any
+  server *name* works, dots included.
+- Delete the file to go back to one server. There is no flag to disable it,
+  because a file you have to write by hand is already the opt-in.
+
+### If your agent is Codex
+
+When `--exec` starts with `codex` and uses the `exec` subcommand, the CLI does
+the same three things it does for Claude Code, through Codex's own flags. The
+detection is just as narrow: interactive `codex`, a wrapper script, a command
+that already says `codex exec resume` / `codex exec review`, or one
+carrying its own unquoted prompt (`codex exec Be-terse`) keep the plain
+stdin/stdout contract untouched. That last one matters: Codex takes exactly one
+prompt positional, so the CLI cannot add its own alongside yours. Shell syntax
+inside a recognisable Codex command — quoting, escapes, expansions, globs,
+comments, redirects, pipelines or lists — instead fails before Codex starts.
+The harness cannot safely make a whitespace scan agree with both POSIX shells
+and `cmd.exe`, and treating such a command as plain would silently drop MCP
+isolation. Ordinary unquoted Windows path separators remain supported. Put
+standing instructions in the agent's ProhostAI profile instead — they arrive at
+the top of the prompt, ahead of everything else.
+
+| | Claude Code | Codex |
+| --- | --- | --- |
+| Reply read from | `--output-format json` | `--json` (JSONL event stream) |
+| Conversation kept with | `--resume <id>` | `codex exec resume <thread>` |
+| Tools wired via | `--mcp-config` | one verified `-c mcp_servers={…}` override |
+| API key travels in | `~/.prohost/mcp.json` (`chmod 600`) | the child's environment |
+| Tools ungated by | `--dangerously-skip-permissions` | `--yolo` |
+
+`--skip-git-repo-check` is also passed on every Codex run, and it is not
+optional: your agent works in `~/.prohost/workspace`, which is not a git
+repository, and Codex refuses to start there without it.
+
+If you already pass `--yolo` (or `--dangerously-bypass-approvals-and-sandbox`)
+in your own `--exec`, the CLI won't add a second one — passing both is an
+argument error that would fail every run. `--safe-tools` works the same way it
+does for Claude Code, and it *removes* a bypass flag you wrote yourself rather
+than just declining to add one, so the gating it promises is real. (It covers
+the full bypass only; `--full-auto` still auto-approves inside Codex's sandbox.)
+
+**Your own MCP servers are switched off for agent runs.** Codex has no
+`--strict-mcp-config`, so the CLI does the same job a different way: before each run
+it asks your binary what servers it has (`codex mcp list --json`) and passes one
+`-c mcp_servers={"<name>"={enabled=false}, …}` covering all of them. A run then
+holds the ProhostAI server, plus anything in your `extra-mcp.json`, and nothing
+else — the same boundary the Claude Code path gets. Each server's own definition
+is left intact; only this invocation sees it disabled.
+
+Two mechanisms that look like they should do this do not, and are worth naming
+so nobody reaches for them. Replacing the `mcp_servers` table does not replace
+it — Codex deep-merges config overrides, so your servers survive alongside
+whatever the override adds. And `--ignore-user-config` works, but throws away
+your model, profile and sandbox settings along with your servers.
+
+The enumeration asks the binary rather than reading `~/.codex/config.toml`,
+because that file is not the whole story: on a normal install `codex mcp list`
+reports servers that appear nowhere in it. It also handles names a dotted-path
+override cannot address — a server called `fly.io` written as
+`-c mcp_servers.fly.io.enabled=false` addresses a three-segment path and Codex
+rejects the whole config, which is why the name goes inside the value instead.
+Every probe also runs in the exact directory the eventual Codex process will
+use. That matters because a trusted project's `.codex/config.toml` is another
+config layer: probing where the harness was launched and then running in
+`$PROHOST_HOME/workspace` or an explicit `--workdir` would certify one MCP
+inventory and execute another.
+
+**The override is checked before it is used**, and one case needs it.
+`{enabled=false}` merges onto a server's existing definition, and a server
+contributed by a **plugin** has no `mcp_servers` entry to merge onto — so the
+override leaves a table with no transport and Codex refuses to start at all.
+The CLI therefore runs the disable past `codex mcp list` first, falls back to
+checking each server individually if the combined form is rejected, and then
+verifies the exact final override. If any configured server cannot be disabled,
+or if the final listing does not show the ProhostAI server and every accepted
+extra enabled, the run fails before Codex starts. Remove that server/plugin or
+use Claude Code.
+
+If the enumeration fails outright — an older Codex without `mcp list --json`,
+or output the CLI doesn't recognise — the run fails before Codex starts. A
+paired run never proceeds under `--yolo` when its MCP boundary cannot be proven.
+Nothing here changes what your Codex config does outside agent runs.
+
+**One gap that cannot be closed from here: profiles.** If your `--exec` runs
+Codex under a named profile (`codex exec -p work`), that profile's
+`work.config.toml` can define MCP servers of its own — and `codex mcp list` has
+no way to be asked about a profile (`-p` and `--profile` are rejected, and the
+`-c profile="…"` form is refused as a removed legacy spelling). Servers defined
+only inside a profile are therefore invisible to the sweep. The CLI fails the
+run before Codex starts when it sees a profile flag; run the agent without `-p`.
+
+The same fail-closed rule applies to `-c` / `--config`, `--enable`, `--disable`,
+`--ignore-user-config`, and `-C` / `--cd` in `--exec`. Those flags can change
+config, plugin loading, or the project config discovery directory for the real
+invocation, while the separate `codex mcp list` verifier cannot safely replay
+an arbitrary shell command's arguments. Use the harness's `--workdir` when you
+need a different directory; dedicated flags such as `--model` and `--sandbox`
+remain supported.
+
+The survey is retaken before every invocation, because
+`install-daemon` runs for weeks and Codex rereads its configuration on every
+invocation — a server you install on Tuesday would otherwise be reachable from
+the next run. The log stays quiet unless the answer changes.
+
+**Refused tools are reported**, as of 0.2.3. Codex has no `permission_denials`
+field, but a refused call arrives as an `mcp_tool_call` item with
+`status: "failed"` and `user cancelled MCP tool call`, and the CLI prints those
+in the same line the Claude Code path uses. A tool call that failed for any
+other reason — an MCP server that 500s — is deliberately not reported as a
+denial, so the log doesn't send you to your permissions when the problem is
+your network.
+
+Your ProhostAI API key is passed to Codex in the child process's environment
+rather than in the `-c` override, because a command line is readable by anyone
+on the machine via `ps` and a process environment is not. Literal `headers`,
+`http_headers`, and stdio `env` values in `extra-mcp.json` get the same
+treatment: the CLI translates them to Codex's environment-indirection fields,
+so their values do not appear in process arguments.
+
 Runs are handled one at a time, and each run executes **at most once on this
 machine** — even across restarts. Started runs are recorded in
 `~/.prohost/runs.json` before the command launches, so a webhook redelivery
@@ -193,8 +369,11 @@ someone in your ProhostAI workspace asks. Be clear-eyed about what that means:
 - **The agent runs as you.** Same user, same filesystem, same SSH keys, same
   logged-in CLIs. It is not sandboxed.
 - **By default its tools are not gated.** With `--dangerously-skip-permissions`
-  (the default for Claude Code) nothing pauses for confirmation. That is what
-  makes it useful and it is also the whole risk.
+  (Claude Code) or `--yolo` (Codex) nothing pauses for confirmation. That is
+  what makes it useful and it is also the whole risk.
+- **Its standing instructions come from the ProhostAI agent profile.** Whoever
+  can edit that profile is configuring a brain that runs unsandboxed on this
+  machine. Treat edit access to it as access to your laptop.
 - **The instructions come from other people.** The prompt carries a message a
   teammate wrote, plus thread history. Treat all of it as untrusted input — the
   same judgement you'd apply to any agent reading text from the internet. A
@@ -204,16 +383,17 @@ someone in your ProhostAI workspace asks. Be clear-eyed about what that means:
 What the harness does to bound this: the message reaches your command on
 **stdin only**, never the shell, so it cannot inject a command; runs execute at
 most once each; every event's signature is verified before anything runs; the
-agent works in `~/.prohost/workspace` rather than your code; and
-`--strict-mcp-config` keeps your own MCP servers out of the run.
+agent works in `~/.prohost/workspace` rather than your code; and, on Claude
+Code, `--strict-mcp-config` keeps your own MCP servers out of the run. Codex has
+no equivalent — see "If your agent is Codex".
 
 What it does **not** do: sandbox the process. If that matters for your machine,
 run `agent run` inside a container or a dedicated user account, or use
 `--safe-tools` and accept that the agent will answer rather than act.
 
-Other agents: the CLI shapes no command but Claude Code's, so give yours its own
-equivalent flag — `codex --yolo` for Codex CLI, whatever your runner calls it —
-and apply the same judgement.
+Other agents: the CLI shapes no command but Claude Code's and Codex's, so give
+yours its own equivalent flag — whatever your runner calls it — and apply the
+same judgement.
 
 ### `agent run` flags
 
@@ -227,7 +407,7 @@ and apply the same judgement.
 | `--machine` | OS hostname | Name shown next to the connection in ProhostAI. |
 | `--url` | paired value | Websocket endpoint override. Pairing stores the URL the server reports, so you should not normally need this. |
 | `--allow-unverified` | off | Run events whose signature can't be verified. See below. |
-| `--safe-tools` | off | Gate the agent's tools behind permission prompts instead of bypassing them. Claude Code only. Alias: `--no-skip-permissions`. |
+| `--safe-tools` | off | Gate the agent's tools behind permission prompts instead of bypassing them. Claude Code and Codex only. Alias: `--no-skip-permissions`. |
 
 ### Keeping it running
 
@@ -307,8 +487,9 @@ Everything the CLI stores lives under `~/.prohost` (`$PROHOST_HOME` moves it):
 | --- | --- |
 | `agent.json` | Credentials. Delete to un-pair locally; revoke in ProhostAI to invalidate the key itself. |
 | `runs.json` | Runs already executed on this machine, so a redelivery can't run your agent twice. |
-| `sessions.json` | Conversation → Claude Code session, for continuity. Safe to delete; costs the agent its memory of open threads. |
+| `sessions.json` | Conversation → Claude Code session / Codex thread, for continuity. Safe to delete; costs the agent its memory of open threads. |
 | `mcp.json` | Generated MCP config. Holds your API key — `chmod 600`. |
+| `extra-mcp.json` | Optional, written by you. Extra MCP servers to expose to agent runs — see "Giving the agent other MCP servers". Never created by the CLI. |
 | `workspace/` | Where your agent command runs by default. |
 | `agent.log` | Daemon output. |
 

package/dist/agent/claude.d.ts

@@ -14,13 +14,8 @@
  * session is unresumable, if the JSON is not what we expect — the run still
  * happens and still completes. These are enhancements that must fail soft.
  */
-/**
- * Name the ProhostAI MCP server is registered under, which is also what makes
- * its tools appear as `mcp__prohost__<tool>`. Referenced in the prompt, in the
- * `--allowedTools` pattern, and in the config file — keep them in sync from
- * here rather than by hand.
- */
-export declare const MCP_SERVER_NAME = "prohost";
+import { MCP_SERVER_NAME } from './mcp.js';
+export { MCP_SERVER_NAME };
 /**
  * What goes to `--allowedTools` so the ProhostAI tools are callable.
  *
@@ -92,7 +87,10 @@ export interface ClaudeFlags {
  * servers in the operator's own configuration with ours, so a run answering a
  * customer's question would hold whatever MCP servers they use for their day
  * job — with permission checks off. Ours is the only one this run is entitled
- * to.
+ * to, plus whatever the operator listed in `extra-mcp.json` — a file they had
+ * to write by hand, which is the point: the boundary still holds, and crossing
+ * it is a decision somebody made on purpose rather than one their day-job
+ * config made for them.
  */
 export declare function claudeCommand(base: string, flags?: ClaudeFlags): string;
 /** What the harness got back from one Claude Code invocation. */
@@ -136,10 +134,25 @@ export declare function looksLikeResumeFailure(output: string, sessionId: string
 /** Absolute path of the generated MCP config. */
 export declare function mcpConfigPath(env?: NodeJS.ProcessEnv): string;
 export interface McpConfigOptions {
-    /** The MCP endpoint the pairing reported, e.g. `https://connect.prohost.ai/mcp`. */
-    mcpUrl: string;
+    /**
+     * The MCP endpoint the pairing reported, e.g. `https://connect.prohost.ai/mcp`.
+     *
+     * Optional, because a pairing can carry none — and a run with no ProhostAI
+     * server is still a run whose operator may have opted into extras. Omitted,
+     * the generated config holds only those, and `--strict-mcp-config` still
+     * keeps everything else out.
+     */
+    mcpUrl?: string;
     /** The paired API key. Written to a `0600` file and nowhere else. */
     apiKey: string;
+    /**
+     * Servers the operator opted into via `$PROHOST_HOME/extra-mcp.json`.
+     *
+     * Merged in *under* ours, never over it: {@link loadExtraMcpServers} already
+     * refuses an entry named `prohost`, and writing ours last means even a future
+     * bug there cannot end with a run's workspace tools pointed somewhere else.
+     */
+    extraServers?: Record<string, Record<string, unknown>>;
     env?: NodeJS.ProcessEnv;
 }
 /**

package/dist/agent/claude.js

@@ -17,13 +17,9 @@
 import { chmodSync, mkdirSync, writeFileSync } from 'node:fs';
 import path from 'node:path';
 import { prohostHome } from './credentials.js';
-/**
- * Name the ProhostAI MCP server is registered under, which is also what makes
- * its tools appear as `mcp__prohost__<tool>`. Referenced in the prompt, in the
- * `--allowedTools` pattern, and in the config file — keep them in sync from
- * here rather than by hand.
- */
-export const MCP_SERVER_NAME = 'prohost';
+import { MCP_SERVER_NAME } from './mcp.js';
+import { SHELL_CONTROL_OPERATORS, shellQuote } from './shell.js';
+export { MCP_SERVER_NAME };
 /**
  * What goes to `--allowedTools` so the ProhostAI tools are callable.
  *
@@ -75,27 +71,6 @@ export function isClaudeExec(command) {
         return false;
     return words.some((word) => word === '-p' || word === '--print');
 }
-/** Pipes, lists, redirections, subshells — anything that makes "append to the end" wrong. */
-const SHELL_CONTROL_OPERATORS = /[|&;<>(){}`]|\$\(/;
-/**
- * Quote a value for a `shell: true` command line on this platform.
- *
- * Every value that goes through here is ours or the operator's — a session id
- * we stored, a path under `$PROHOST_HOME` — never event-derived text. It is
- * quoted anyway: a home directory with a space in it is ordinary, and "the
- * inputs are trusted" is the assumption that stops being true the first time
- * someone extends this.
- *
- * Windows needs its own branch. `shell: true` there runs `cmd.exe`, where a
- * single quote is an ordinary character rather than a quoting one — POSIX
- * quoting would hand Claude Code a config path with literal apostrophes around
- * it, and the tools would simply never load.
- */
-function shellQuote(value, platform) {
-    if (platform === 'win32')
-        return `"${value.replace(/"/g, '""')}"`;
-    return `'${value.replace(/'/g, `'\\''`)}'`;
-}
 /**
  * Append the flags this harness needs to a Claude Code command.
  *
@@ -112,13 +87,29 @@ function shellQuote(value, platform) {
  * servers in the operator's own configuration with ours, so a run answering a
  * customer's question would hold whatever MCP servers they use for their day
  * job — with permission checks off. Ours is the only one this run is entitled
- * to.
+ * to, plus whatever the operator listed in `extra-mcp.json` — a file they had
+ * to write by hand, which is the point: the boundary still holds, and crossing
+ * it is a decision somebody made on purpose rather than one their day-job
+ * config made for them.
  */
 export function claudeCommand(base, flags = {}) {
     const platform = flags.platform ?? process.platform;
     const quote = (value) => shellQuote(value, platform);
     const skipPermissions = flags.skipPermissions !== false;
-    const parts = [base.trim(), '--output-format', 'json'];
+    // `--safe-tools` removes the bypass rather than merely declining to add it.
+    // A host who wrote `--dangerously-skip-permissions` into their own `--exec`
+    // and *also* passed `--safe-tools` is contradicting themselves, and the only
+    // safe way to resolve that is in favour of the flag whose entire purpose is
+    // to gate — otherwise the harness announces "tools are permission-gated" over
+    // a run that bypasses every one of them.
+    const command = skipPermissions
+        ? base.trim()
+        : base
+            .trim()
+            .split(/\s+/)
+            .filter((word) => word !== '--dangerously-skip-permissions')
+            .join(' ');
+    const parts = [command, '--output-format', 'json'];
     if (skipPermissions)
         parts.push('--dangerously-skip-permissions');
     if (flags.sessionId)
@@ -280,8 +271,11 @@ export function mcpConfigPath(env = process.env) {
  * the filesystem, and so the header scheme is stated in exactly one place.
  */
 export function buildMcpConfig(options) {
+    if (!options.mcpUrl)
+        return { mcpServers: { ...(options.extraServers ?? {}) } };
     return {
         mcpServers: {
+            ...(options.extraServers ?? {}),
             [MCP_SERVER_NAME]: {
                 type: 'http',
                 // Verbatim, exactly as pairing reported it. An earlier revision appended