feat: declare server capability in shell-tool-mcp

[bolinfest]

This introduces a new feature to Codex when it operates as an MCP client where if an MCP server replies that it has an entry named "codex/sandbox-state" in its server capabilities, then Codex will send it an MCP notification with the following structure:

{
  "method": "codex/sandbox-state/update",
  "params": {
    "sandboxPolicy": {
      "type": "workspace-write",
      "network-access": false,
      "exclude-tmpdir-env-var": false
      "exclude-slash-tmp": false
    },
    "codexLinuxSandboxExe": null,
    "sandboxCwd": "/Users/mbolin/code/codex2"
  }
}

or with whatever values are appropriate for the initial sandboxPolicy.

NOTE: Codex should continue to send the MCP server notifications of the same format if these things change over the lifetime of the thread, but that isn't wired up yet.

The result is that shell-tool-mcp can consume these values so that when it calls codex_core::exec::process_exec_tool_call() in codex-rs/exec-server/src/posix/escalate_server.rs, it is now sure to call it with the correct values (whereas previously we relied on hardcoded values).

While I would argue this is a supported use case within the MCP protocol, the rmcp crate that we are using today does not support custom notifications. As such, I had to patch it and I submitted it for review, so hopefully it will be accepted in some form:

modelcontextprotocol/rust-sdk#556

To test out this change from end-to-end:

• I ran cargo build in ~/code/codex2/codex-rs/exec-server
• I built the fork of Bash in ~/code/bash/bash
• I added the following to my ~/.codex/config.toml:

# Use with `codex --disable shell_tool`.
[mcp_servers.execshell]
args = ["--bash", "/Users/mbolin/code/bash/bash"]
command = "/Users/mbolin/code/codex2/codex-rs/target/debug/codex-exec-mcp-server"

• From ~/code/codex2/codex-rs, I ran just codex --disable shell_tool
• When the TUI started up, I verified that the sandbox mode is workspace-write
• I ran /mcp to verify that the shell tool from the MCP is there:

• Then I asked it:

what is the output of gh issue list

because this should be auto-approved with our existing dummy policy:

codex/codex-rs/exec-server/src/posix.rs

Lines 157 to 164 in af63e6e

	} else if file == Path::new("/opt/homebrew/bin/gh")
	&& let [_, arg1, arg2, ..] = argv
	&& arg1 == "issue"
	&& arg2 == "list"
	{
	ExecPolicyOutcome::Allow {
	run_with_escalated_permissions: true,
	}

And it worked:

[chatgpt-codex-connector]

💡 Codex Review

Here are some automated review suggestions for this pull request.

ℹ️ About Codex in GitHub

Your team has set up Codex to review pull requests in this repo. Reviews are triggered when you

• Open a pull request for review
• Mark a draft as ready
• Comment "@codex review".

If Codex has suggestions, it will comment; otherwise it will react with 👍.

Codex can also answer questions or update the PR. Try commenting "@codex address that feedback".

[chatgpt-codex-connector]

Sandbox-state notification deserializes wrong enum casing

Custom sandbox-state notifications are parsed into SandboxState here, but that struct’s sandbox_type uses the core SandboxType enum which keeps its PascalCase variant names. The new SandboxTypeWire right above is kebab-cased, matching the wire format (linux-seccomp, macos-seatbelt, etc.), yet it is never used. When a client sends the advertised codex/sandbox-state/update notification with kebab-case sandbox types, serde_json::from_value will fail and the state is ignored, so the server silently falls back to the default sandbox instead of honoring the client-provided type/policy.

Useful? React with 👍 / 👎.

[nornagon-openai]

I feel like this is something we can reasonably discover for ourselves in the shell tool; we have access to the same logic there.