@prohost/cli 0.2.2 → 0.2.3

package/CHANGELOG.md

@@ -4,6 +4,121 @@ 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

package/README.md

@@ -179,23 +179,88 @@ 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 pipeline,
-a command that already says `codex exec resume` / `codex exec review`, or one
-carrying its own prompt (`codex exec 'Be terse'`) all keep the plain
+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. Put standing
-instructions in the agent's ProhostAI profile instead — they arrive at the top
-of the prompt, ahead of everything else.
+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` | `-c mcp_servers.prohost={…}` |
+| 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` |
 
@@ -210,22 +275,83 @@ 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.)
 
-**Two things Codex cannot do that Claude Code can**, both worth knowing before
-you leave it running:
-
-- **Your own MCP servers come along.** There is no Codex equivalent of
-  `--strict-mcp-config`. `--ignore-user-config` looks like one but drops the
-  `-c` overrides too, taking the ProhostAI server with them — so a Codex run
-  also holds whatever servers your `~/.codex/config.toml` defines, with
-  approvals bypassed. The CLI prints this at start-up so it isn't a surprise.
-  If that matters, keep `~/.codex/config.toml` free of servers you would not
-  hand to a teammate's message.
-- **Refused tools stay invisible.** Claude Code reports what it was denied and
-  the CLI prints it; Codex's event stream has no equivalent.
+**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.
+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
@@ -363,6 +489,7 @@ Everything the CLI stores lives under `~/.prohost` (`$PROHOST_HOME` moves it):
 | `runs.json` | Runs already executed on this machine, so a redelivery can't run your agent twice. |
 | `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

@@ -87,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. */
@@ -131,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

@@ -87,7 +87,10 @@ export function isClaudeExec(command) {
  * 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;
@@ -268,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