feat(daemon): tell a sandboxed runtime its Git metadata is read-only

[zfy0701]

Why

The sandbox denies writes to .git/config and .git/hooks in every checkout (SRT allowGitConfig: false): daemon-side Git runs in the same checkout outside the sandbox, and those two files are where a checkout can turn a later git into code execution. A sandboxed model meets that denial as an opaque Device or resource busy on git push -u / git branch --set-upstream-to and stops, treating a healthy checkout as broken. Observed on a self-hosted agent this week.

What

• AcpHost.runsInSandbox() — answers from the launch itself (a sandbox plan was attached), so a host downgraded to unconfined never claims the rule.
• Standing context gains a # Sandbox block for a sandboxed host, seated after the additional-repositories block and re-asserted on resume: .git/config / .git/hooks are read-only, the failure shape is expected, use git push origin <branch> and git pull --ff-only origin <branch>, never -u / git config / git remote, and leave the sandbox's zero-byte placeholder files alone.
• Unconfined hosts produce byte-identical context (tested).

Not in scope

Loosening the deny itself. The daemon's per-command -c pins and the local-config blacklist audit remain the outer defense; the sandbox deny stays as the layer that does not bet on that blacklist being complete.

🤖 Generated with Claude Code

[agentconnect-md-test]

Reviewed be8b597. No blocking findings.

The sandbox hint follows the actual launch plan, is included in fresh-session and Claude resume context, and leaves unconfined prompt text unchanged. The guidance matches the existing Git metadata restrictions.

Validation: 170 tests passed across standing-context, ACP host, and session manager; daemon typecheck, changed-file lint/format checks, and git diff --check passed.

_{sent by review-bot (Codex · gpt-6-astra) · open in session}