@prohost/cli 0.4.0 → 0.4.2

package/CHANGELOG.md

@@ -4,6 +4,82 @@ 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.4.2
+
+Isolated Codex runs no longer receive the operator's **apps (connectors)**.
+
+- **`codex_apps` tools are kept out of every run.** A Codex "app" is a set of
+  MCP tools served under the name `codex_apps`, and it appears in **no**
+  `codex mcp list --json` output at any setting: apps are account-level, arrive
+  with the ChatGPT login, and are cached under `$CODEX_HOME/cache/codex_apps_tools`
+  rather than declared in `mcp_servers`. The isolation contract is that a run
+  gets the ProhostAI server and the operator's explicitly-allowed extras and
+  nothing else, and this broke it silently — the enumeration the guarantee is
+  built on cannot see these tools at all. Every isolated run now carries
+  `-c features.apps=false`.
+- **It was not hypothetical, and not limited to plugin installs.** Measured
+  against codex-cli 0.146.0: a `CODEX_HOME` whose config declares no plugins
+  and one ordinary MCP server — where 0.4.1 disables that server cleanly, finds
+  nothing that resists, and therefore applies no whole-config override at all —
+  still handed the run 28 `mcp__codex_apps__*` tools. They are not read-only:
+  `sites_create_site`, `sites_deploy_site_version`, `sites_add_custom_domain`,
+  `sites_update_environment_variables`, `sites_generate_siwc_bypass_token`,
+  `plugin_management_update_app_permissions` and
+  `plugin_management_uninstall_app` publish sites and rewrite app permissions on
+  the operator's own account.
+- **A dedicated `CODEX_HOME` was never a fix for this one.** A directory holding
+  only `auth.json` — 0.4.1's own suggested remedy — fetches the account's apps
+  on its first run, writes them to its own cache, and serves the full set from
+  the second run onwards. The login carries them, so a fresh directory delays
+  the exposure by exactly one run. Hence unconditional rather than opt-in.
+- **`features.plugins=false` was the wrong lever, and only ever worked by
+  accident.** It closed this on plugin-bearing machines because apps happened to
+  arrive through that pipeline there, but it leaves the apps instructions in the
+  prompt, costs the operator their plugin skills and hooks, and is never applied
+  at all on a classic-only install. `features.apps=false` is the narrow switch:
+  it leaves `plugins` on, so skills and hooks survive.
+- **Proven, not assumed.** There is no listing to verify against, so the switch
+  is read back out of `codex features list` — the `apps` row must actually read
+  `false` under the exact overrides the run will carry. A renamed feature, an
+  older Codex with no `features` subcommand, or an override that loads and
+  changes nothing all read as *unknown*, and a run that cannot prove the
+  boundary fails before Codex starts with a one-line remedy. 0.4.1's plugin
+  handling, three-tier probe path and classic `mcp_servers` disabling are
+  unchanged and regression-tested.
+
+## 0.4.1
+
+Codex runs work again on machines with a Codex **plugin** installed.
+
+- **Plugin-provided MCP servers are now isolated instead of blocking the run.**
+  A plugin declared in `~/.codex/config.toml` — `[plugins."github@openai-curated"]`
+  — contributes an MCP server (`github`) that the per-server `mcp_servers`
+  disable cannot touch: it has no `mcp_servers` entry for `{enabled=false}` to
+  merge onto, so the override leaves a table with no transport and Codex
+  rejects the whole config with `invalid transport in mcp_servers.github`. The
+  isolation verifier correctly refused to start a run it could not prove was
+  sealed, which meant **every** message to a Codex-backed agent failed with
+  `MCP isolation could not be established`. Such servers are now shut off with
+  `-c features.plugins=false`, verified by re-listing exactly like every other
+  disable.
+- **Only when a plugin actually supplies a server.** An install whose plugins
+  contribute no MCP server issues byte-identical commands to 0.4.0 and keeps
+  its plugin skills and hooks; the switch is a bigger hammer than the problem
+  on those machines. Classic `mcp_servers` entries are still disabled
+  individually, and the ProhostAI server and any `extra-mcp.json` servers keep
+  working with plugins off.
+- **Nothing is trusted that wasn't verified.** Every per-plugin form that looks
+  like it should work — `plugins."github@openai-curated".enabled=false`, the
+  same written as a table, `.disabled=true`, a whole-table `plugins={…}` —
+  loads without error and changes nothing at all. A silent no-op is the worst
+  shape a security override can have, and only the re-list distinguishes it
+  from one that took.
+- **The failure message now carries the way out.** When a server still cannot
+  be disabled, the error names the remedy — remove it from
+  `~/.codex/config.toml`, or run the daemon with a dedicated `CODEX_HOME`
+  holding only `auth.json` — rather than leaving the operator with a run that
+  will not start and nothing to do about it.
+
 ## 0.4.0
 
 The wall clock stops being the safety mechanism. 0.3.0 raised the run ceiling

package/README.md

@@ -301,16 +301,83 @@ 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.
+**The override is checked before it is used.** `{enabled=false}` merges onto a
+server's existing definition, so an entry Codex cannot make sense of takes the
+whole config down rather than disabling anything. 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.
+
+**Codex plugins get a second mechanism, because `mcp_servers` cannot reach
+them.** A plugin declared in your config — say `[plugins."github@openai-curated"]`
+— contributes an MCP server (`github`) that has *no* `mcp_servers` entry for
+`{enabled=false}` to merge onto, so forcing one leaves a table with no transport
+and Codex rejects the config outright: `invalid transport in mcp_servers.github`.
+Nothing in `codex mcp list --json` marks a server as plugin-provided, so the CLI
+measures instead of guessing: it lists again with plugins off, and the names that
+vanish were the plugin's. Those are shut off for the run with
+`-c features.plugins=false`, verified by re-listing like any other disable.
+
+This is applied **only when a plugin actually supplies an MCP server**. Plugins
+also carry skills and hooks, and switching the system off costs you those, so an
+install whose plugins contribute no server keeps everything and gets exactly the
+command line it got before. Your own `prohost` server and your `extra-mcp.json`
+servers are unaffected either way. Per-plugin spellings are deliberately not
+used: `plugins."github@openai-curated".enabled=false` and every variant of it
+load without error and disable nothing at all, which is precisely the kind of
+override the verification step exists to catch.
+
+**Your apps (connectors) are switched off for every run, unconditionally.**
+Codex "apps" are the third way tools reach a run, and the only one with no
+inventory to read: an app *is* a set of MCP tools, served under the name
+`codex_apps`, and it appears in **no** `codex mcp list --json` output at any
+setting. Apps are account-level — they come with your ChatGPT login and are
+cached under `$CODEX_HOME/cache/codex_apps_tools`, not declared in
+`mcp_servers`. On the install this was measured against they were 28 tools, and
+they are not read-only: `sites_create_site`, `sites_deploy_site_version`,
+`sites_add_custom_domain`, `sites_update_environment_variables`,
+`sites_generate_siwc_bypass_token`, `plugin_management_update_app_permissions`
+and `plugin_management_uninstall_app` publish sites and rewrite app permissions
+on your account.
+
+So this one is not applied on evidence, the way the plugins switch is — there is
+no listing to take evidence from. Every isolated run carries
+`-c features.apps=false`, and the CLI reads the result back out of
+`codex features list` to confirm the `apps` row really flipped. If it cannot
+confirm that, the run fails before Codex starts, for the same reason a server
+that will not disable fails it: an override that loads happily and changes
+nothing is the failure mode this whole path exists to catch.
+
+`features.plugins=false` is **not** a substitute. It costs you your plugin
+skills and hooks, it leaves the apps instructions in the prompt, and on an
+install with no plugin-backed server it is never applied at all — which is
+exactly the shape that was quietly receiving these tools before 0.4.2. Turning
+apps off leaves `plugins` on, so plugin skills and hooks survive; what a run
+loses is your connectors, which is the intent. The run executes on behalf of
+whoever mentioned the agent, and your connectors are yours.
+
+**If a server still cannot be disabled**, the run fails before Codex starts and
+names it. Two ways out: remove that server or plugin from `~/.codex/config.toml`,
+or give the daemon a `CODEX_HOME` of its own that holds only `auth.json` —
+
+```bash
+mkdir -p ~/.prohost/codex-home
+cp ~/.codex/auth.json ~/.prohost/codex-home/auth.json
+CODEX_HOME=~/.prohost/codex-home prohost agent run --exec 'codex exec'
+```
+
+A dedicated `CODEX_HOME` is the cleanest answer in general: the agent inherits
+your login and nothing else, your own Codex setup is untouched, and no future
+plugin or server you install can change what a paired run can reach.
+
+It is not, however, an answer to apps. A `CODEX_HOME` holding only `auth.json`
+fetches your account's apps on its first run, writes them to its own cache, and
+serves the full set from the second run onwards — the login is what carries
+them, so a fresh directory only delays it by one run. That is why the apps
+switch is unconditional rather than something an operator can opt out of by
+tidying their config.
 
 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

package/dist/agent/codex.d.ts

@@ -190,7 +190,44 @@ export type CommandRunner = (command: string, cwd?: string) => {
  * nothing to disable, while `null` means we do not know, and a run that cannot
  * enumerate must say so rather than claim an isolation it did not apply.
  */
-export declare function listMcpServers(binary: string, runner: CommandRunner, override?: string, cwd?: string): CodexMcpServer[] | null;
+export declare function listMcpServers(binary: string, runner: CommandRunner, overrides?: string | string[], cwd?: string): CodexMcpServer[] | null;
+/**
+ * The Codex feature that supplies the `codex_apps` MCP.
+ *
+ * Its own prompt text is the definition, and it is worth quoting because
+ * nothing else in the CLI says it: *"An app is equivalent to a set of MCP tools
+ * within the `codex_apps` MCP."* Apps are the operator's **connectors** —
+ * account-level, not config-level.
+ */
+export declare const APPS_FEATURE = "apps";
+/**
+ * Read one feature's *effective* state, under the overrides the run will carry.
+ *
+ * This is {@link listMcpServers}'s counterpart for the thing that listing cannot
+ * see, and it exists because `codex_apps` appears in **no** MCP inventory:
+ * `codex mcp list --json` reports the operator's servers and says nothing about
+ * apps, so the entire 0.4.1 verification path is blind to 28 tools the run
+ * actually gets.
+ *
+ * `codex features list` answers it — it prints `<name> <stage> <state>` per
+ * feature and honours `-c`, so asking it under the run's own overrides turns
+ * "did the switch take" into a measurement rather than an assumption. Measured
+ * at ~0.14s with no network, so it is cheap enough to run every time.
+ *
+ * Only the one requested row is read, deliberately unlike `listMcpServers`,
+ * which fails the whole answer on a single malformed entry. There the *set* is
+ * the boundary, so an unparsed member is a hole; here the question is about one
+ * named key, and refusing to answer because some unrelated future row gained a
+ * column would break every run to protect nothing. The last whitespace-separated
+ * token is the state — the stage column is sometimes two words (`under
+ * development`), so the row is read from both ends rather than by field index.
+ *
+ * Returns `null` when the answer is unknown: the command failed (a malformed
+ * override makes `features list` exit 1 and print nothing), the feature has no
+ * row, or its state is not a boolean. A renamed or retired feature therefore
+ * reads as unknown rather than as "off", and the caller fails the run closed.
+ */
+export declare function featureState(binary: string, runner: CommandRunner, feature: string, overrides?: string | string[], cwd?: string): boolean | null;
 /** Disable entries proven to work, and the servers that could not be disabled. */
 export interface VerifiedDisable {
     entries: string[];
@@ -216,8 +253,135 @@ export interface VerifiedDisable {
  * `failed` is the honest part. A server that cannot be disabled is still
  * reachable from the run, and the caller has to say so out loud rather than
  * report an isolation it only partly achieved.
+ *
+ * `baseOverrides` are config overrides the run will also carry —
+ * {@link APPS_DISABLED_OVERRIDE} always, and {@link PLUGINS_DISABLED_OVERRIDE}
+ * when a plugin supplies a server. They have to be present on every probe here,
+ * because "does this entry disable this server" has a different answer under a
+ * different config, and the answer that matters is the one for the config the
+ * run actually gets.
  */
-export declare function disableEntriesThatLoad(binary: string, runner: CommandRunner, targets: string[], cwd?: string): VerifiedDisable;
+export declare function disableEntriesThatLoad(binary: string, runner: CommandRunner, targets: string[], cwd?: string, baseOverrides?: string[]): VerifiedDisable;
+/**
+ * The one override that switches off Codex's plugin system for a single run.
+ *
+ * Needed because a Codex **plugin** contributes MCP servers that the
+ * `mcp_servers` mechanism cannot touch. `[plugins."github@openai-curated"]` in
+ * `~/.codex/config.toml` puts a `github` server in `codex mcp list` that has no
+ * `mcp_servers` entry to merge `{enabled=false}` onto, so the override defines
+ * a table with no transport and Codex rejects the entire config: `invalid
+ * transport in mcp_servers.github`. That is the failure this harness shipped
+ * with — fail-closed and correct, but it meant no run at all on any machine
+ * with a Codex plugin installed.
+ *
+ * Measured against `codex-cli 0.146.0`, and the measurements are the reason
+ * this is a whole-system switch rather than the per-plugin one it should be:
+ *
+ * - `plugins."github@openai-curated".enabled=false`, the same spelled as a
+ *   table, `plugins.github.enabled=false`, `.disabled=true`, `.mcp_servers={}`
+ *   and a whole-table `plugins={…}` **all load without error and change
+ *   nothing** — the server is still listed, still enabled. A silent no-op is
+ *   the worst shape a security override can have, and it is exactly why
+ *   {@link disableEntriesThatLoad} verifies instead of trusting.
+ * - `features.plugins` is a *stable* Codex feature, on by default. Setting it
+ *   false removes plugin-contributed servers from `codex mcp list --json`
+ *   **entirely** (they are absent, not `enabled: false`) while leaving classic
+ *   `mcp_servers` entries and this harness's own `prohost` server untouched.
+ * - The effect is real at runtime, not just in the listing: the same run asked
+ *   for its tool list reported 28 `mcp__codex_apps__*` tools without this
+ *   override and none with it.
+ * - `--ignore-user-config` also works, and is still the wrong tool: it drops
+ *   the operator's model, profile and sandbox settings too.
+ *
+ * Applied only when a plugin actually contributes a server (see
+ * {@link isolateConfiguredServers}). Plugins carry skills and hooks as well, so
+ * an install whose plugins contribute no MCP servers keeps all of that.
+ */
+export declare const PLUGINS_DISABLED_OVERRIDE = "features.plugins=false";
+/**
+ * The one override that keeps the operator's **apps (connectors)** out of a run.
+ *
+ * Applied to every isolated run, unconditionally, which is the whole point of
+ * it. Measured against `codex-cli 0.146.0`:
+ *
+ * - `codex_apps` is the {@link APPS_FEATURE} surface, and `apps` is a *stable*
+ *   Codex feature that is **on by default**. Turning it off removes the
+ *   `<apps_instructions>` block from the prompt and all 28 `mcp__codex_apps__*`
+ *   tools from the run, while leaving `plugins` — and so the operator's plugin
+ *   skills and hooks — switched on.
+ * - Those tools are not read-only. They include `sites_create_site`,
+ *   `sites_deploy_site_version`, `sites_add_custom_domain`,
+ *   `sites_update_environment_variables`, `sites_generate_siwc_bypass_token`,
+ *   `plugin_management_update_app_permissions` and
+ *   `plugin_management_uninstall_app`: publishing sites and rewriting app
+ *   permissions on the operator's own ChatGPT account.
+ * - **Nothing in `codex mcp list --json` mentions any of it.** Apps are
+ *   account-level and cached under `$CODEX_HOME/cache/codex_apps_tools`, not
+ *   declared in `mcp_servers`, so the entire server-enumeration path this module
+ *   is built on cannot see them. That is why this is unconditional rather than
+ *   applied on evidence, as {@link PLUGINS_DISABLED_OVERRIDE} is: there is no
+ *   listing to take evidence from.
+ * - It is not enough to have no plugins and no configured servers. A
+ *   `CODEX_HOME` holding **only `auth.json`** — 0.4.1's own suggested remedy —
+ *   fetches the account's apps on its first run, writes them to that cache, and
+ *   serves all 28 tools from the second run onwards. Measured, not reasoned.
+ *
+ * `features.plugins=false` also happens to remove the tools on installs where
+ * apps arrive through the plugin pipeline, which is why 0.4.1 closed this by
+ * accident on plugin-bearing machines. It is the wrong lever regardless: it
+ * leaves `<apps_instructions>` in the prompt, it costs the operator their plugin
+ * skills and hooks, and it does nothing at all on a classic-only install —
+ * exactly the shape where 0.4.1 applies no override.
+ */
+export declare const APPS_DISABLED_OVERRIDE = "features.apps=false";
+/** A verified isolation: what to pass Codex, and what could not be shut off. */
+export interface VerifiedIsolation {
+    /** `mcp_servers` fragments, for the single {@link mcpServersOverride}. */
+    entries: string[];
+    /** Whole-config `-c` overrides the run needs on top. Never empty. */
+    configOverrides: string[];
+    /** Servers still reachable from the run. Empty is the outcome we want. */
+    failed: string[];
+    /**
+     * Why a whole-config switch could not be *proven* to have taken effect.
+     *
+     * Separate from {@link failed}, which names MCP servers and earns a remedy
+     * about `mcp_servers`. This one is not a server and has no such remedy, so it
+     * carries its own sentence. Set means the run must not start.
+     */
+    unproven?: string;
+}
+/**
+ * Shut off every server the operator's install has, whatever supplies it.
+ *
+ * Two mechanisms, because Codex has two kinds of MCP server and one lever does
+ * not move both: `mcp_servers` entries are disabled individually
+ * ({@link disableEntriesThatLoad}), plugin-contributed ones only by
+ * {@link PLUGINS_DISABLED_OVERRIDE}. Nothing in `codex mcp list --json` says
+ * which is which — a plugin's server is reported with the same fields as any
+ * other, no source or plugin marker anywhere in the object — so provenance is
+ * *measured* rather than read: list again with plugins off, and the names that
+ * vanished were the plugin's.
+ *
+ * A **third** mechanism sits underneath both and is not a server at all: the
+ * operator's apps (connectors), which reach the run as the `codex_apps` MCP and
+ * appear in no listing this module can read. {@link APPS_DISABLED_OVERRIDE} is
+ * therefore applied to every run unconditionally — there is no inventory to
+ * decide from — and every probe below carries it, so each disable is proven
+ * against the config the run is actually handed.
+ *
+ * The classic path is still tried first and, when it succeeds, returned with no
+ * *plugins* override, so an install with no plugin-backed servers keeps its
+ * plugin skills and hooks and pays the same one probe it did before.
+ *
+ * Failing to shut a server off is reported, never worked around. A plugin
+ * server that survives even `features.plugins=false` is a mechanism we do not
+ * understand yet, and a run that cannot prove the boundary must not start. The
+ * apps switch is held to the same standard: it is *measured* off through
+ * {@link featureState} under the final override set, because an override that
+ * silently does nothing is the failure mode this whole module exists to catch.
+ */
+export declare function isolateConfiguredServers(binary: string, runner: CommandRunner, targets: string[], cwd?: string): VerifiedIsolation;
 /**
  * The `codex` binary out of the host's `--exec` command.
  *
@@ -267,6 +431,15 @@ export interface CodexFlags {
      * {@link buildMcpOverride} for what happens when they don't.
      */
     mcpEntries?: string[];
+    /**
+     * Whole-config `-c` overrides that are not `mcp_servers`:
+     * {@link APPS_DISABLED_OVERRIDE} on every isolated run, plus
+     * {@link PLUGINS_DISABLED_OVERRIDE} when the operator has a plugin that
+     * contributes MCP servers. They precede the `mcp_servers` override for the
+     * same reason they do in the verifier: the run has to be handed the same
+     * overrides in the same order the probe certified.
+     */
+    configOverrides?: string[];
     /**
      * Run with approvals and the sandbox bypassed. Default ON — see
      * {@link codexCommand}. Set false by `agent run --safe-tools`.

package/dist/agent/codex.js

@@ -485,8 +485,14 @@ export function mcpServersOverride(entries) {
  * nothing to disable, while `null` means we do not know, and a run that cannot
  * enumerate must say so rather than claim an isolation it did not apply.
  */
-export function listMcpServers(binary, runner, override, cwd) {
-    const command = override ? `${binary} mcp list --json -c ${shellQuote(override, process.platform)}` : `${binary} mcp list --json`;
+export function listMcpServers(binary, runner, overrides, cwd) {
+    // Several overrides rather than one, because they land in different config
+    // tables: `mcp_servers={…}` cannot also carry `features.plugins=false`. Codex
+    // applies repeated `-c` in order, and the run must be given this same list in
+    // this same order or the probe certifies a config the run does not get.
+    const list = overrides === undefined ? [] : typeof overrides === 'string' ? [overrides] : overrides;
+    const flags = list.map((value) => ` -c ${shellQuote(value, process.platform)}`).join('');
+    const command = `${binary} mcp list --json${flags}`;
     let result;
     try {
         result = runner(command, cwd);
@@ -518,6 +524,67 @@ export function listMcpServers(binary, runner, override, cwd) {
         return null;
     }
 }
+/**
+ * The Codex feature that supplies the `codex_apps` MCP.
+ *
+ * Its own prompt text is the definition, and it is worth quoting because
+ * nothing else in the CLI says it: *"An app is equivalent to a set of MCP tools
+ * within the `codex_apps` MCP."* Apps are the operator's **connectors** —
+ * account-level, not config-level.
+ */
+export const APPS_FEATURE = 'apps';
+/**
+ * Read one feature's *effective* state, under the overrides the run will carry.
+ *
+ * This is {@link listMcpServers}'s counterpart for the thing that listing cannot
+ * see, and it exists because `codex_apps` appears in **no** MCP inventory:
+ * `codex mcp list --json` reports the operator's servers and says nothing about
+ * apps, so the entire 0.4.1 verification path is blind to 28 tools the run
+ * actually gets.
+ *
+ * `codex features list` answers it — it prints `<name> <stage> <state>` per
+ * feature and honours `-c`, so asking it under the run's own overrides turns
+ * "did the switch take" into a measurement rather than an assumption. Measured
+ * at ~0.14s with no network, so it is cheap enough to run every time.
+ *
+ * Only the one requested row is read, deliberately unlike `listMcpServers`,
+ * which fails the whole answer on a single malformed entry. There the *set* is
+ * the boundary, so an unparsed member is a hole; here the question is about one
+ * named key, and refusing to answer because some unrelated future row gained a
+ * column would break every run to protect nothing. The last whitespace-separated
+ * token is the state — the stage column is sometimes two words (`under
+ * development`), so the row is read from both ends rather than by field index.
+ *
+ * Returns `null` when the answer is unknown: the command failed (a malformed
+ * override makes `features list` exit 1 and print nothing), the feature has no
+ * row, or its state is not a boolean. A renamed or retired feature therefore
+ * reads as unknown rather than as "off", and the caller fails the run closed.
+ */
+export function featureState(binary, runner, feature, overrides, cwd) {
+    const list = overrides === undefined ? [] : typeof overrides === 'string' ? [overrides] : overrides;
+    const flags = list.map((value) => ` -c ${shellQuote(value, process.platform)}`).join('');
+    let result;
+    try {
+        result = runner(`${binary} features list${flags}`, cwd);
+    }
+    catch {
+        return null;
+    }
+    if (result.status !== 0)
+        return null;
+    for (const line of result.stdout.split('\n')) {
+        const words = line.trim().split(/\s+/);
+        if (words.length < 2 || words[0] !== feature)
+            continue;
+        const state = words[words.length - 1];
+        if (state === 'true')
+            return true;
+        if (state === 'false')
+            return false;
+        return null;
+    }
+    return null;
+}
 /**
  * Disable entries, checked against the binary before they are used.
  *
@@ -537,15 +604,22 @@ export function listMcpServers(binary, runner, override, cwd) {
  * `failed` is the honest part. A server that cannot be disabled is still
  * reachable from the run, and the caller has to say so out loud rather than
  * report an isolation it only partly achieved.
+ *
+ * `baseOverrides` are config overrides the run will also carry —
+ * {@link APPS_DISABLED_OVERRIDE} always, and {@link PLUGINS_DISABLED_OVERRIDE}
+ * when a plugin supplies a server. They have to be present on every probe here,
+ * because "does this entry disable this server" has a different answer under a
+ * different config, and the answer that matters is the one for the config the
+ * run actually gets.
  */
-export function disableEntriesThatLoad(binary, runner, targets, cwd) {
+export function disableEntriesThatLoad(binary, runner, targets, cwd, baseOverrides = []) {
     if (targets.length === 0)
         return { entries: [], failed: [] };
     const disabled = (names) => {
         const override = mcpServersOverride(disableMcpEntries(names));
         if (!override)
             return [];
-        const listing = listMcpServers(binary, runner, override, cwd);
+        const listing = listMcpServers(binary, runner, [...baseOverrides, override], cwd);
         // A config that does not load disables nothing, and a server the listing
         // still reports as enabled was not disabled whatever the override said.
         if (listing === null)
@@ -570,6 +644,149 @@ export function disableEntriesThatLoad(binary, runner, targets, cwd) {
         failed: targets.filter((name) => !verified.includes(name)),
     };
 }
+/**
+ * The one override that switches off Codex's plugin system for a single run.
+ *
+ * Needed because a Codex **plugin** contributes MCP servers that the
+ * `mcp_servers` mechanism cannot touch. `[plugins."github@openai-curated"]` in
+ * `~/.codex/config.toml` puts a `github` server in `codex mcp list` that has no
+ * `mcp_servers` entry to merge `{enabled=false}` onto, so the override defines
+ * a table with no transport and Codex rejects the entire config: `invalid
+ * transport in mcp_servers.github`. That is the failure this harness shipped
+ * with — fail-closed and correct, but it meant no run at all on any machine
+ * with a Codex plugin installed.
+ *
+ * Measured against `codex-cli 0.146.0`, and the measurements are the reason
+ * this is a whole-system switch rather than the per-plugin one it should be:
+ *
+ * - `plugins."github@openai-curated".enabled=false`, the same spelled as a
+ *   table, `plugins.github.enabled=false`, `.disabled=true`, `.mcp_servers={}`
+ *   and a whole-table `plugins={…}` **all load without error and change
+ *   nothing** — the server is still listed, still enabled. A silent no-op is
+ *   the worst shape a security override can have, and it is exactly why
+ *   {@link disableEntriesThatLoad} verifies instead of trusting.
+ * - `features.plugins` is a *stable* Codex feature, on by default. Setting it
+ *   false removes plugin-contributed servers from `codex mcp list --json`
+ *   **entirely** (they are absent, not `enabled: false`) while leaving classic
+ *   `mcp_servers` entries and this harness's own `prohost` server untouched.
+ * - The effect is real at runtime, not just in the listing: the same run asked
+ *   for its tool list reported 28 `mcp__codex_apps__*` tools without this
+ *   override and none with it.
+ * - `--ignore-user-config` also works, and is still the wrong tool: it drops
+ *   the operator's model, profile and sandbox settings too.
+ *
+ * Applied only when a plugin actually contributes a server (see
+ * {@link isolateConfiguredServers}). Plugins carry skills and hooks as well, so
+ * an install whose plugins contribute no MCP servers keeps all of that.
+ */
+export const PLUGINS_DISABLED_OVERRIDE = 'features.plugins=false';
+/**
+ * The one override that keeps the operator's **apps (connectors)** out of a run.
+ *
+ * Applied to every isolated run, unconditionally, which is the whole point of
+ * it. Measured against `codex-cli 0.146.0`:
+ *
+ * - `codex_apps` is the {@link APPS_FEATURE} surface, and `apps` is a *stable*
+ *   Codex feature that is **on by default**. Turning it off removes the
+ *   `<apps_instructions>` block from the prompt and all 28 `mcp__codex_apps__*`
+ *   tools from the run, while leaving `plugins` — and so the operator's plugin
+ *   skills and hooks — switched on.
+ * - Those tools are not read-only. They include `sites_create_site`,
+ *   `sites_deploy_site_version`, `sites_add_custom_domain`,
+ *   `sites_update_environment_variables`, `sites_generate_siwc_bypass_token`,
+ *   `plugin_management_update_app_permissions` and
+ *   `plugin_management_uninstall_app`: publishing sites and rewriting app
+ *   permissions on the operator's own ChatGPT account.
+ * - **Nothing in `codex mcp list --json` mentions any of it.** Apps are
+ *   account-level and cached under `$CODEX_HOME/cache/codex_apps_tools`, not
+ *   declared in `mcp_servers`, so the entire server-enumeration path this module
+ *   is built on cannot see them. That is why this is unconditional rather than
+ *   applied on evidence, as {@link PLUGINS_DISABLED_OVERRIDE} is: there is no
+ *   listing to take evidence from.
+ * - It is not enough to have no plugins and no configured servers. A
+ *   `CODEX_HOME` holding **only `auth.json`** — 0.4.1's own suggested remedy —
+ *   fetches the account's apps on its first run, writes them to that cache, and
+ *   serves all 28 tools from the second run onwards. Measured, not reasoned.
+ *
+ * `features.plugins=false` also happens to remove the tools on installs where
+ * apps arrive through the plugin pipeline, which is why 0.4.1 closed this by
+ * accident on plugin-bearing machines. It is the wrong lever regardless: it
+ * leaves `<apps_instructions>` in the prompt, it costs the operator their plugin
+ * skills and hooks, and it does nothing at all on a classic-only install —
+ * exactly the shape where 0.4.1 applies no override.
+ */
+export const APPS_DISABLED_OVERRIDE = `features.${APPS_FEATURE}=false`;
+/**
+ * Shut off every server the operator's install has, whatever supplies it.
+ *
+ * Two mechanisms, because Codex has two kinds of MCP server and one lever does
+ * not move both: `mcp_servers` entries are disabled individually
+ * ({@link disableEntriesThatLoad}), plugin-contributed ones only by
+ * {@link PLUGINS_DISABLED_OVERRIDE}. Nothing in `codex mcp list --json` says
+ * which is which — a plugin's server is reported with the same fields as any
+ * other, no source or plugin marker anywhere in the object — so provenance is
+ * *measured* rather than read: list again with plugins off, and the names that
+ * vanished were the plugin's.
+ *
+ * A **third** mechanism sits underneath both and is not a server at all: the
+ * operator's apps (connectors), which reach the run as the `codex_apps` MCP and
+ * appear in no listing this module can read. {@link APPS_DISABLED_OVERRIDE} is
+ * therefore applied to every run unconditionally — there is no inventory to
+ * decide from — and every probe below carries it, so each disable is proven
+ * against the config the run is actually handed.
+ *
+ * The classic path is still tried first and, when it succeeds, returned with no
+ * *plugins* override, so an install with no plugin-backed servers keeps its
+ * plugin skills and hooks and pays the same one probe it did before.
+ *
+ * Failing to shut a server off is reported, never worked around. A plugin
+ * server that survives even `features.plugins=false` is a mechanism we do not
+ * understand yet, and a run that cannot prove the boundary must not start. The
+ * apps switch is held to the same standard: it is *measured* off through
+ * {@link featureState} under the final override set, because an override that
+ * silently does nothing is the failure mode this whole module exists to catch.
+ */
+export function isolateConfiguredServers(binary, runner, targets, cwd) {
+    // Present on every probe from here down, and on the run itself.
+    const base = [APPS_DISABLED_OVERRIDE];
+    const prove = (isolation) => {
+        if (featureState(binary, runner, APPS_FEATURE, isolation.configOverrides, cwd) === false) {
+            return isolation;
+        }
+        return {
+            ...isolation,
+            unproven: `Codex would not confirm its "${APPS_FEATURE}" feature is off, so the operator's apps ` +
+                '(connectors) and their tools cannot be kept out of this run',
+        };
+    };
+    const direct = disableEntriesThatLoad(binary, runner, targets, cwd, base);
+    if (direct.failed.length === 0)
+        return prove({ ...direct, configOverrides: base });
+    // Something resisted. Ask whether turning the plugin system off accounts for
+    // it, rather than assuming the survivors are plugin-backed because they look
+    // like it.
+    const withPluginsOff = listMcpServers(binary, runner, [...base, PLUGINS_DISABLED_OVERRIDE], cwd);
+    // The override does not load, so it disables nothing and we know nothing.
+    if (withPluginsOff === null)
+        return prove({ ...direct, configOverrides: base });
+    const remaining = new Set(withPluginsOff.map((server) => server.name));
+    const removedByPluginsOff = direct.failed.filter((name) => !remaining.has(name));
+    // Plugins were not the problem. Report what the classic path found, so the
+    // operator is told about the real survivor instead of a plugin red herring.
+    if (removedByPluginsOff.length === 0)
+        return prove({ ...direct, configOverrides: base });
+    // Re-verify the classic disables *under* the plugins-off override. They were
+    // proven against a different config, and a proof about a config the run does
+    // not get is not a proof.
+    const classic = targets.filter((name) => remaining.has(name));
+    const configOverrides = [...base, PLUGINS_DISABLED_OVERRIDE];
+    const verified = disableEntriesThatLoad(binary, runner, classic, cwd, configOverrides);
+    return prove({
+        entries: verified.entries,
+        configOverrides,
+        failed: verified.failed,
+    });
+}
 /**
  * The `codex` binary out of the host's `--exec` command.
  *
@@ -705,6 +922,8 @@ export function codexCommand(base, flags = {}) {
     if (!gated && !has(words, ...BYPASS_FLAGS)) {
         parts.push('--yolo');
     }
+    for (const value of flags.configOverrides ?? [])
+        parts.push('-c', quote(value));
     const override = mcpServersOverride(flags.mcpEntries ?? []);
     if (override)
         parts.push('-c', quote(override));

package/dist/agent/run.d.ts

@@ -146,6 +146,8 @@ interface PreparedMcp {
     mcpConfigPath?: string;
     /** Codex: entries in the single verified `mcp_servers` override. */
     codexMcpEntries?: string[];
+    /** Codex: verified non-`mcp_servers` overrides, e.g. plugins off. */
+    codexConfigOverrides?: string[];
     /** Credentials moved out of Codex's process argv. */
     execEnv?: NodeJS.ProcessEnv;
     /** ProhostAI tools are actually reachable from this invocation. */

package/dist/agent/run.js

@@ -27,7 +27,7 @@ import { spawnSync } from 'node:child_process';
 import WebSocket from 'ws';
 import { completeRun, postReply } from './api.js';
 import { MAX_SALVAGE_CHARS, claudeCommand, isClaudeExec, looksLikeResumeFailure, readClaudeStream, writeMcpConfig, } from './claude.js';
-import { MCP_API_KEY_ENV_VAR, codexBinary, codexCommand, codexMcpInventoryFlag, codexProfileName, codexShellSyntax, disableEntriesThatLoad, extraMcpEntries, isCodexExec, listMcpServers, mcpServersOverride, prohostMcpEntry, looksLikeCodexResumeFailure, parseCodexOutput, } from './codex.js';
+import { APPS_FEATURE, MCP_API_KEY_ENV_VAR, PLUGINS_DISABLED_OVERRIDE, codexBinary, codexCommand, codexMcpInventoryFlag, codexProfileName, codexShellSyntax, extraMcpEntries, isCodexExec, isolateConfiguredServers, listMcpServers, mcpServersOverride, prohostMcpEntry, looksLikeCodexResumeFailure, parseCodexOutput, } from './codex.js';
 import { EXTRA_MCP_FILENAME, loadExtraMcpServers } from './extras.js';
 import { MCP_SERVER_NAME, MCP_TOOL_PATTERN } from './mcp.js';
 import { EVENT_AGENT_RUN_REQUESTED, EVENT_MENTION_CREATED, EVENT_MESSAGE_TEAM_CHAT, RUN_ERROR_CANCELLED_BY_USER, eventData, heartbeatPathFor, parseRunRequest, } from './contract.js';
@@ -329,19 +329,41 @@ function codexMcpEntries(options, extraServers, log, workdir) {
     if (acceptedExtraEntries.length === 0)
         acceptedExtraNames.clear();
     const targets = [...configuredNames].filter((name) => !acceptedExtraNames.has(name));
-    const { entries: disabled, failed } = disableEntriesThatLoad(binary, probe, targets, workdir);
+    const { entries: disabled, configOverrides, failed, unproven } = isolateConfiguredServers(binary, probe, targets, workdir);
+    if (unproven) {
+        // Not an `mcp_servers` problem, so it does not get the `mcp_servers`
+        // remedy. Upgrading Codex is the honest advice: the switch is read back
+        // from `codex features list`, so this fires when that command, the feature,
+        // or its name is not what this harness was measured against.
+        return fail(`${unproven} — upgrade Codex, or run the daemon with a Codex build that reports ` +
+            `"${APPS_FEATURE}" in \`codex features list\``);
+    }
     if (failed.length > 0) {
-        return fail(`these Codex MCP servers could not be disabled: ${failed.join(', ')}`);
+        // The remedy belongs in the message. This string is echoed into the thread
+        // the teammate is waiting in, and "could not be disabled" on its own leaves
+        // them with a run that will not start and nothing to do about it.
+        return fail(`these Codex MCP servers could not be disabled: ${failed.join(', ')} — remove them from ` +
+            '~/.codex/config.toml, or run the daemon with a dedicated CODEX_HOME containing only auth.json');
     }
     entries.push(...disabled);
-    if (disabled.length > 0) {
+    if (targets.length > 0) {
         log(`${timestamp()} ⚙ your own Codex MCP servers are disabled for agent runs: ${targets.join(', ')}`);
     }
+    // Unconditional, so it is stated every run rather than only when something
+    // was found: the operator's connectors are account-level and invisible to
+    // `codex mcp list`, and "nothing was listed" is exactly the wrong thing for
+    // them to conclude from silence here.
+    log(`${timestamp()} ⚙ Codex apps (connectors) are switched off for agent runs`);
+    if (configOverrides.includes(PLUGINS_DISABLED_OVERRIDE)) {
+        log(`${timestamp()} ⚙ Codex plugins are switched off for agent runs — a plugin supplies an MCP ` +
+            'server that cannot be disabled on its own');
+    }
     // Verify the exact combined override, not its pieces. This catches a config
     // merge that re-enables a server and a server installed between the initial
     // survey and this final probe.
     const override = mcpServersOverride(entries);
-    const finalListing = listMcpServers(binary, probe, override, workdir);
+    const runOverrides = [...configOverrides, ...(override ? [override] : [])];
+    const finalListing = listMcpServers(binary, probe, runOverrides, workdir);
     if (finalListing === null)
         return fail('Codex rejected the final isolated MCP configuration');
     const allowed = new Set([
@@ -359,6 +381,7 @@ function codexMcpEntries(options, extraServers, log, workdir) {
     }
     return {
         codexMcpEntries: entries,
+        codexConfigOverrides: configOverrides.length > 0 ? configOverrides : undefined,
         execEnv: Object.keys(execEnv).length > 0 ? execEnv : undefined,
         mcpWired: Boolean(options.credentials.mcp_url),
     };
@@ -573,6 +596,7 @@ async function runTurn(run, prompt, options, runtime, mcp, control, log) {
         ? codexCommand(options.exec, {
             sessionId: resume,
             mcpEntries: mcp.codexMcpEntries,
+            configOverrides: mcp.codexConfigOverrides,
             skipPermissions: runtime.skipPermissions,
         })
         : claudeCommand(options.exec, {

package/dist/version.d.ts

@@ -7,6 +7,6 @@
  * `package.json`, so a release bump that forgets this file fails the suite
  * instead of shipping a `User-Agent` that lies about which build is calling.
  */
-export declare const CLI_VERSION = "0.4.0";
+export declare const CLI_VERSION = "0.4.2";
 /** Sent on every HTTP request the CLI makes back into ProhostAI. */
-export declare const USER_AGENT = "prohost-cli/0.4.0";
+export declare const USER_AGENT = "prohost-cli/0.4.2";

package/dist/version.js

@@ -7,6 +7,6 @@
  * `package.json`, so a release bump that forgets this file fails the suite
  * instead of shipping a `User-Agent` that lies about which build is calling.
  */
-export const CLI_VERSION = '0.4.0';
+export const CLI_VERSION = '0.4.2';
 /** Sent on every HTTP request the CLI makes back into ProhostAI. */
 export const USER_AGENT = `prohost-cli/${CLI_VERSION}`;

package/package.json

@@ -1,6 +1,6 @@
 {
   "name": "@prohost/cli",
-  "version": "0.4.0",
+  "version": "0.4.2",
   "description": "Run your own AI agent as a ProhostAI teammate, and stream your account's webhooks to your laptop.",
   "type": "module",
   "license": "MIT",