Names and rationales are not capabilities
Use when: your agent can choose among multiple execution environments, two threads can reuse the same MCP server name, or a tool call may execute after the catalog or runtime has refreshed.
sandbox_permissions
value,
and
require
the
escalated
enum
before
entering
approval
flow.
Store
the
finalized
ToolRouter
and
MCP
binding
on
the
step
context.
Dispatch
readiness
checks,
argument
handling,
cancellation,
parallelism,
and
execution
through
that
stored
object—never
by
re-resolving
the
current
global
registry.
Acceptance check: in a disposable harness, configure Thread A and Thread B with different MCP processes under the same server name, each returning a unique marker. Give the plan two local environments. First submit a rationale-only shell call; pass only if validation rejects it before process start. Confirm the bare shell tool is absent and an external tool cannot claim that reserved name, while qualified variants remain available. Then alternate A/B MCP calls, refresh A between sampling and dispatch, and execute an A call that was already planned. Pass only if every call returns its thread marker, the in-flight A call uses its sampled step binding, and refreshed capabilities appear only in a newly sampled step.
Caveat: Codex 0.147.0-alpha.4 is prerelease, and no independent field reproduction was available at this scan. The field names and router types are product-specific. A binding proves dispatch consistency, not that the selected tool is safe or that escalation should be approved; policy still needs an external deny path.