Domain-scoped credential injection for sandboxed sessions

Setup

Claude Code with sandbox.enabled: true and the credential protections doing their job: credentials.envVars strips tokens, credentials.files masks ~/.config/gh, and the OS keyring is unreachable twice over (a read deny on ~/.local/share/keyrings, plus seccomp blocking the AF_UNIX socket D-Bus needs). This is the hardening working as designed: a sandboxed session cannot use the operator's credentials by any route.

The problem

There is no way to let a confined process authenticate to one chosen destination. The only mechanism that restores credentials is sandbox.excludedCommands - and that restores everything at once, because an excluded command runs outside the sandbox entirely.

Measured (2026-07-21): the same CLI invocation, differing only in path prefix, flips between authenticated and not.

• gh-axi issue list -R owner/name (matches an excludedCommands entry) - authenticated
• /abs/path/gh-axi issue list -R owner/name (no longer matches) - AUTH_REQUIRED

The consequence is that the exclusion list becomes the credential policy, expressed as enumerated verb prefixes. That works, but it couples two unrelated things: what may leave the sandbox, and what may authenticate. When one needs widening, the only move available widens the other too, and that is always the wrong direction.

Ask

Let a credential be scoped to a destination rather than to a command string - for example: "this token is injectable for requests to github.com/<org>". A confined process could then authenticate without also being unconfined, and the exclusion list would go back to being about execution surface only, which is what it should have been.

Happy to provide more measurements or test a design if useful.