Bash sandbox default denies git push/fetch, npm install/build, and loopback-only Postgres

Summary

In a standard full-stack repo (Node/Next.js + Prisma/Postgres, hosted on GitHub), nearly every git/npm/gh command that touches the network fails under the default Bash sandbox with "Operation not permitted": git push, git fetch, npm ci, npm run build, npx prisma migrate deploy/generate, gh pr create/merge. So does purely loopback Postgres access (psql -h localhost, createdb, dropdb), which isn't external network traffic at all.

Impact

In a same-day survey of 14 concurrent Claude Code sessions working on one private repo, 6+ sessions independently flagged this as their single largest source of friction. One session logged 15+ separate escalations to dangerouslyDisableSandbox for entirely routine git operations in a single sitting. In a repo where nearly all useful work is git/npm/gh, the sandbox default barely narrows anything down — it's a retry round-trip on almost every command rather than a meaningful safety boundary.

Reproduction

1. Open a Claude Code session in any git repo with a configured remote and a local Postgres database.
2. Ask it to run any of: git push, git fetch, npm ci, npx prisma migrate deploy, psql -h localhost -p 5432 -c '\dt'.
3. Observe "Operation not permitted" under the default sandbox; the same command succeeds immediately with dangerouslyDisableSandbox: true.

Suggested fix

Default-allow loopback destinations (127.0.0.1/::1) and the git remote host(s) already configured for the current working repo. These are the expected baseline for nearly any software project's day-to-day workflow, not an edge case that should require an escalation every time.