sayan-oai 4213b38f3c Honor attachment-owned permissions for MCP servers (#40728) ...

## Why

MCP servers attached to executor environments must retain their owner's
permission profile instead of inheriting the thread-wide sandbox authority.

## What changed

- Resolve and capture a permission profile for each enabled MCP server when
  publishing the runtime, and reject calls or elicitations when that authority
  is unavailable.
- Use the captured server profile for tool approval decisions, elicitation, and
  sandbox metadata, including after runtime refreshes.
- Materialize `:workspace_roots` from `PathUri` values so permissions preserve
  the path convention of remote executor environments.
- Give threadless app discovery and resource reads an explicit default
  permission profile.

## Testing

Added coverage for per-server elicitation authority, unresolved attachments,
runtime refreshes, restricted tool calls, and foreign-platform workspace roots.

GitOrigin-RevId: 6b188d4b08b29e9971ff7aa68a7785a0cdf9e394

2026-08-25 22:50:49 +00:00

..

src

Honor attachment-owned permissions for MCP servers (#40728)

2026-08-25 22:50:49 +00:00

BUILD.bazel

Extract MCP into codex-mcp crate (#15919)

2026-04-01 19:03:26 -07:00

Cargo.toml

Reconnect MCP servers when authentication mode changes (#40634)

2026-08-25 16:14:26 +00:00