@prohost/cli 0.4.1 → 0.4.2

package/CHANGELOG.md

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

package/README.md

@@ -329,6 +329,35 @@ 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` —
@@ -343,6 +372,13 @@ 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
 paired run never proceeds under `--yolo` when its MCP boundary cannot be proven.

package/dist/agent/codex.d.ts

@@ -191,6 +191,43 @@ export type CommandRunner = (command: string, cwd?: string) => {
  * enumerate must say so rather than claim an isolation it did not apply.
  */
 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[];
@@ -217,11 +254,12 @@ export interface VerifiedDisable {
  * 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 — in practice
- * {@link PLUGINS_DISABLED_OVERRIDE}. 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.
+ * `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, baseOverrides?: string[]): VerifiedDisable;
 /**
@@ -260,14 +298,58 @@ export declare function disableEntriesThatLoad(binary: string, runner: CommandRu
  * 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. Usually empty. */
+    /** 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.
@@ -281,14 +363,23 @@ export interface VerifiedIsolation {
  * *measured* rather than read: list again with plugins off, and the names that
  * vanished were the plugin's.
  *
- * The classic path is tried first and, when it succeeds, returned untouched
- * with no extra override. So an install with no plugin-backed servers issues
- * byte-identical commands to the version before plugins were handled at all,
- * and pays exactly one probe as before.
+ * 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.
+ * 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;
 /**
@@ -341,8 +432,9 @@ export interface CodexFlags {
      */
     mcpEntries?: string[];
     /**
-     * Whole-config `-c` overrides that are not `mcp_servers` — in practice
-     * {@link PLUGINS_DISABLED_OVERRIDE}, when the operator has a plugin that
+     * 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.

package/dist/agent/codex.js

@@ -524,6 +524,67 @@ export function listMcpServers(binary, runner, overrides, 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.
  *
@@ -544,11 +605,12 @@ export function listMcpServers(binary, runner, overrides, cwd) {
  * 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 — in practice
- * {@link PLUGINS_DISABLED_OVERRIDE}. 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.
+ * `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, baseOverrides = []) {
     if (targets.length === 0)
@@ -618,6 +680,42 @@ export function disableEntriesThatLoad(binary, runner, targets, cwd, baseOverrid
  * 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.
  *
@@ -630,42 +728,64 @@ export const PLUGINS_DISABLED_OVERRIDE = 'features.plugins=false';
  * *measured* rather than read: list again with plugins off, and the names that
  * vanished were the plugin's.
  *
- * The classic path is tried first and, when it succeeds, returned untouched
- * with no extra override. So an install with no plugin-backed servers issues
- * byte-identical commands to the version before plugins were handled at all,
- * and pays exactly one probe as before.
+ * 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.
+ * 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) {
-    const direct = disableEntriesThatLoad(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 { ...direct, configOverrides: [] };
+        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, PLUGINS_DISABLED_OVERRIDE, cwd);
+    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 { ...direct, configOverrides: [] };
+        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 { ...direct, configOverrides: [] };
+        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 verified = disableEntriesThatLoad(binary, runner, classic, cwd, [PLUGINS_DISABLED_OVERRIDE]);
-    return {
+    const configOverrides = [...base, PLUGINS_DISABLED_OVERRIDE];
+    const verified = disableEntriesThatLoad(binary, runner, classic, cwd, configOverrides);
+    return prove({
         entries: verified.entries,
-        configOverrides: [PLUGINS_DISABLED_OVERRIDE],
+        configOverrides,
         failed: verified.failed,
-    };
+    });
 }
 /**
  * The `codex` binary out of the host's `--exec` command.

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, PLUGINS_DISABLED_OVERRIDE, codexBinary, codexCommand, codexMcpInventoryFlag, codexProfileName, codexShellSyntax, extraMcpEntries, isCodexExec, isolateConfiguredServers, 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,7 +329,15 @@ function codexMcpEntries(options, extraServers, log, workdir) {
     if (acceptedExtraEntries.length === 0)
         acceptedExtraNames.clear();
     const targets = [...configuredNames].filter((name) => !acceptedExtraNames.has(name));
-    const { entries: disabled, configOverrides, failed } = isolateConfiguredServers(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) {
         // 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
@@ -341,6 +349,11 @@ function codexMcpEntries(options, extraServers, log, workdir) {
     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');

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.1";
+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.1";
+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.1';
+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.1",
+  "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",