fix(core): keep the lead mcp endpoint out of process environments #528

Summary

An ACP lead's bridge process carries its MCP endpoint, which includes the lead run's token, in its environment. On macOS a crew worker can read another process's environment and command line, so it could call Orbyn's MCP as the lead. Keep the token out of any process environment and argv.

Parity rows

none

Checklist

• Pass the bridge endpoint through a file in the run's own folder or standard input, not the environment
• Check that no other token, data folder path or service address sits in a long-lived process's argv or environment
• Test that a worker cannot read the lead's MCP endpoint from another process
• Update the confinement limits in docs/crew.md and SPEC.md section 11 once closed

Done when

A worker cannot learn the lead's MCP endpoint or any Orbyn token by reading another process's command line or environment, and a test shows it.

Area

Core

Platforms

macOS, Windows

AI usage

AI helped

AI details

Claude Code, claude-opus-5-5 and claude-sonnet-5-5 (built and reviewed), medium

Before you submit

• I searched existing issues and found no duplicate.

Notes

From the Opus review of PR #527 (macOS worker confinement, refs #441). A probe with the PR's profile read another process's environment through sysctl KERN_PROCARGS2, and pgrep -lf printed the full orbynd command line including --data-dir. A deny rule for that sysctl did not block it. The source is crates/orbyn-core/src/agents/acp_mcp_bridge.rs, which sets ORBYN_ACP_MCP_ENDPOINT.