fix: confine Agent and MCP data access

docs/adr/0018-agent-execution-surface-bounded-by-workspace.md

@@ -92,12 +92,25 @@ The boundary is enforced by the Claude Code SDK's built-in sandbox
 - `sandbox.enabled: true` + `failIfUnavailable: true` — the agent process and
   its Bash subprocesses run sandboxed; if the sandbox can't start, `query()`
   emits an error and exits rather than running unsandboxed.
-- `sandbox.filesystem.allowWrite: [workspaceDir]` — writes confined to the
-  workspace (the ADR-0007 directory tree). Reads outside are allowed by
-  default (the agent may read system files for context), but sensitive host
-  paths are denied via `denyRead` (`/etc`, `/root`, `~/.ssh`, `~/.aws`, …).
-- `sandbox.filesystem.denyRead: SENSITIVE_READ_PATHS` — defense-in-depth;
-  extends via `CPH_SANDBOX_EXTRA_DENY_READ` for deployment-specific secrets.
+- `sandbox.allowUnsandboxedCommands: false` — a tool cannot opt out with the
+  SDK's `dangerouslyDisableSandbox` input.
+- `sandbox.filesystem.denyRead: ["/"]` with `allowRead` for the canonical
+  current workspace and a small named system-runtime set — normal reads stay
+  in the run's workspace while `/bin`, shared libraries, CA certificates,
+  fonts and the configured `cph` executable remain available as the external
+  tool exception described above.
+- `sandbox.filesystem.allowWrite: [workspaceDir]` — writes are confined to the
+  canonical ADR-0007 workspace; SDK temp/config/cache/home paths are relocated
+  beneath `.cph/agent-runtime/` in that same workspace.
+- The SDK subprocess environment replaces rather than spreads `process.env`.
+  Only provider protocol variables and non-secret runtime variables cross the
+  boundary; database, Feishu and Hub session credentials never enter it.
+  `sandbox.credentials` denies provider token variables inside Bash and denies
+  configured credential files. `CPH_SANDBOX_EXTRA_DENY_READ` names additional
+  deployment-specific secret paths on the Hub side only.
+- `settingSources: []` and strict MCP configuration prevent an untrusted
+  workspace or service-user config from widening tools, hooks, MCP servers, or
+  sandbox paths.
 - Network: open (see Open Questions).
 
 `bypassPermissions` is kept (headless server — no interactive prompts); the
@@ -146,13 +159,13 @@ as it upholds `AgentFileOp.Authorized`.
   tradeoff for CLI integration simplicity. This is revisitable — a network
   allowlist (`sandbox.network.allowedDomains`) can be added without a spec
   change if the threat model tightens.
-- **Sensitive read path coverage.** `SENSITIVE_READ_PATHS` in `runner.ts`
-  covers `/etc`, `/root`, `/var/log`, `/proc`, `/sys`, and common
-  credential dirs (`~/.ssh`, `~/.aws`, `~/.config/gcloud`, `~/.gnupg`).
-  Deployments with additional secret locations extend via
-  `CPH_SANDBOX_EXTRA_DENY_READ` (colon-separated). Whether this set should be
-  spec-pinned rather than implementation-chosen is `OPEN` — it's plumbing, not
-  a semantic divergence, so currently left out of `spec/`.
+- **Named system-runtime read set.** The implementation allows only the
+  platform runtime directories/files needed for shell, dynamic libraries,
+  fonts, TLS/DNS and `cph` execution in addition to the project workspace.
+  Expanding that set requires an explicit reviewed code change. Deployments
+  name credential files with `CPH_SANDBOX_EXTRA_DENY_READ`; these paths are
+  protected through the SDK credential layer and are not passed to the Agent
+  environment. The exact runtime set remains plumbing and is not spec-pinned.
 - **Shell command vocabulary.** Whether the agent's Bash is restricted to a
   whitelist (e.g. `cph`, `ls`, `grep`) or allowed arbitrary commands whose
   *effects* are then confined, is a policy choice left to implementation. The