enforce repo-pinned retrieval-only code-indexer MCP capability

[sixtoad]

Context

Walk will own managed code-indexer lifecycle and MCP provisioning as specified by Walk #90. Leash must enforce the resulting capability boundary without becoming a code-indexer provider or consumer.

This contract must work identically whether the sandbox workload is BME or a direct agent such as Codex, Claude, or extcc.

Required enforcement contract

For a target sandbox, Leash permits only the single code-indexer MCP endpoint or process channel explicitly supplied by Walk. That channel is restricted to retrieval-only operations against the repository and revision selected for the run.

Leash must prevent:

• starting or reaching duplicate or otherwise unapproved code-indexer/MCP servers;
• indexing, re-indexing, deletion, configuration changes, or other mutation through the approved retrieval channel;
• access to another repository or revision through that channel;
• exposure of raw host code-indexer configuration, stores, database credentials, provider credentials, or unrelated indexes to the sandbox;
• broad filesystem or network authority being inferred merely because code-indexer retrieval was requested.

Denied attempts and the effective approved capability must be auditable. All endpoint/process-channel grants and supporting resources must be removed on success, failure, cancellation, and signal.

Acceptance criteria

• Leash accepts a bounded, machine-readable capability description for exactly one Walk-provided code-indexer MCP endpoint or process channel per target sandbox.
• The approved channel permits only retrieval operations for the declared repository and revision; indexing and every other mutation operation are denied.
• A request for a different repository or revision is denied, including same-host and same-service cross-repository attempts.
• A second, undeclared, or substituted code-indexer/MCP server cannot be started or reached from the sandbox.
• The target receives no raw host code-indexer configuration, backing-store path, backing-store credentials, provider credentials, or unrelated index data.
• The policy is fail-closed when the capability description is absent, malformed, ambiguous, stale, or cannot be enforced.
• Effective grants and denials identify the sandbox, operation class, repository/revision scope, and endpoint/channel without logging secrets or retrieved source contents.
• Endpoint/process-channel access and every temporary enforcement resource are cleaned up on success, startup failure, workload failure, cancellation, and signal.
• Equivalent integration tests prove the contract for both BME-mediated execution and a direct MCP-capable agent; neither path receives broader authority.
• Existing default-deny filesystem, network, process, and credential protections remain unchanged when code-indexer is not requested.
• Documentation clearly assigns lifecycle/index freshness/MCP provisioning to Walk and enforcement only to Leash.

Non-goals

• Installing, starting, indexing, or refreshing code-indexer in Leash.
• Selecting repository context or deciding whether retrieval is required.
• Implementing BME-specific retrieval behavior.

Coordination

Provider-side lifecycle, exact-revision freshness, and MCP injection are tracked in Walk #90. This issue defines the corresponding Leash enforcement boundary.