[Feature Request] Sandbox permission prompts should show the triggering command and reason, not just the target host

Resolved 💬 3 comments Opened Mar 11, 2026 by mpro7 Closed May 1, 2026

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 test is requesting network access to repo1.maven.org to download Maven dependencies. Allow? [Allow / Deny]

i.e., include:

  1. The command (or tool call) that triggered the sandbox check
  2. 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.

View original on GitHub ↗

This issue has 3 comments on GitHub. Read the full discussion on GitHub ↗