[Feature Request] Sandbox permission prompts should show the triggering command and reason, not just the target host
Summary
When Claude Code's sandbox blocks a network (or filesystem) access and surfaces a permission prompt, the dialog only shows the target host/path — not _which command_ triggered it or _why_ that command needs access.
Current behaviour
Permission prompt shows:
Allow access to repo1.maven.org? [Allow / Deny]
The user has no immediate context for what triggered this request.
Expected behaviour
Permission prompt shows something like:
sbt testis requesting network access torepo1.maven.orgto download Maven dependencies. Allow? [Allow / Deny]
i.e., include:
- The command (or tool call) that triggered the sandbox check
- A brief reason (if inferrable — e.g., "downloading dependencies", "fetching plugin registry")
Why this matters
Without context, users face a blind trust decision:
- They don't know if the request is expected (build tool fetching deps) or suspicious (a rogue command phoning home)
- They can't make an informed allow/deny choice
- They end up either allowing everything reflexively or blocking legitimate build tool behaviour
Example scenario
Running sbt test in a fresh worktree — sbt contacts Maven Central to check for cached artifact updates. The sandbox surfaces a prompt for repo1.maven.org. Without seeing that sbt test triggered it, it's unclear whether to allow.
Suggested implementation
The sandbox already tracks which tool call (Bash command, network request, etc.) triggered the check. Surface that information in the prompt alongside the target.
A minimal version would be: [command]: [target] — e.g., sbt test → repo1.maven.org.
This issue has 3 comments on GitHub. Read the full discussion on GitHub ↗