You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
{{ message }}
Repository navigation
sandbox network grants don't persist after approving — network access stays denied, fails with context canceled #703
i think i found a bug with zero's sandbox network permissions.
i was trying to run git push to a gitlawb:// remote. zero prompted me for network access, i clicked allow, but the command still failed with context canceled. i retried several times and approved it each time, but it kept failing.
i checked the sandbox state:
zero sandbox policy
network: deny
backend: macos-seatbelt
and zero sandbox grants list returns:
No persistent sandbox grants.
~/.config/zero/sandbox-grants.json also doesn't exist.
so it looks like clicking allow isn't actually persisting or applying the network grant, and the sandbox continues blocking the network request. the context canceled error also makes it pretty difficult to tell that the sandbox is the cause.
running the same git push outside of zero's sandbox worked fine.
environment
zero 0.1.0
macos 15.7.7, sandbox backend macos-seatbelt
repro
$ zero sandbox policy
mode: enforce
network: deny
backend: macos-seatbelt
grants: /Users/macbook/.config/zero/sandbox-grants.json
$ zero sandbox grants list
No persistent sandbox grants.
$ cat ~/.config/zero/sandbox-grants.json
cat: No such file or directory
Confirmed a network-classification gap affecting this repro: Zero classified git clone as network-sensitive, but not git push. As a result, the initial approval for git push did not enable network access in the sandbox and the command depended on post-failure denial detection, which is unreliable when a custom transport exits with context canceled.
I opened #726 to classify git push as network access before execution, so approving the prompt applies the temporary network-enabled sandbox profile immediately.
Regression coverage includes the reported custom-remote shape (git push gitlawb main) at both analyzer and risk-classifier layers. Full tests and vet pass; govulncheck reports no vulnerabilities; diff-scoped lint reports 0 issues.
One clarification: an absent sandbox-grants.json, an empty sandbox grants list, and the base policy continuing to show network: deny are expected for allow-once/session network approvals. Network grants are temporary in-memory overlays rather than persistent shell grants.
Activity
Svector-anu commentedon Jul 16, 2026
PierrunoYT commentedon Jul 17, 2026
Checking now!
PierrunoYT commentedon Jul 18, 2026
Confirmed a network-classification gap affecting this repro: Zero classified
git cloneas network-sensitive, but notgit push. As a result, the initial approval forgit pushdid not enable network access in the sandbox and the command depended on post-failure denial detection, which is unreliable when a custom transport exits withcontext canceled.I opened #726 to classify
git pushas network access before execution, so approving the prompt applies the temporary network-enabled sandbox profile immediately.Regression coverage includes the reported custom-remote shape (
git push gitlawb main) at both analyzer and risk-classifier layers. Full tests and vet pass; govulncheck reports no vulnerabilities; diff-scoped lint reports 0 issues.One clarification: an absent
sandbox-grants.json, an emptysandbox grants list, and the base policy continuing to shownetwork: denyare expected for allow-once/session network approvals. Network grants are temporary in-memory overlays rather than persistent shell grants.fix(sandbox): classify interpreter source as command text
fix(sandbox): classify interpreter source as command text
fix(sandbox): classify interpreter source as command text
fix(sandbox): classify interpreter source as command text
fix(sandbox): classify interpreter source as command text
fix(sandbox): classify interpreter source as command text