ZERO_DAEMON_REMOTE_TOKEN_FILE leaks the daemon bearer token into sandboxed commands

[PierrunoYT]

Summary

PR #660 scrubs ZERO_DAEMON_REMOTE_TOKEN, but leaves ZERO_DAEMON_REMOTE_TOKEN_FILE in the inherited sandbox environment. The read-all sandbox posture lets the command read the referenced file.

Relevant code

• internal/sandbox/runner.go: scrubSensitiveEnv includes ZERO_DAEMON_REMOTE_TOKEN but not ZERO_DAEMON_REMOTE_TOKEN_FILE.
• internal/daemon/remote/auth.go: TokenFromEnv reads the bearer token from that path.

Observed at commit 6fc1220.

Reproduction

1. Put a daemon bearer token in a file outside the workspace.
2. Set ZERO_DAEMON_REMOTE_TOKEN_FILE to its absolute path.
3. Launch a sandboxed command through Zero.
4. The command can read the pointer and token file.

Suggested fix

Remove the pointer from the sandbox environment and add its resolved target to DenyRead, analogous to GOOGLE_APPLICATION_CREDENTIALS. Test both env scrubbing and filesystem denial.

[Vasanthdev2004]

Confirmed on current main, and fixed in #818.

scrubSensitiveEnv (internal/sandbox/runner.go:1008) lists ZERO_DAEMON_REMOTE_TOKEN and nothing matches ZERO_DAEMON_REMOTE_TOKEN_FILE, while TokenFromEnv accepts either form. So the pointer survived into the sandboxed environment and the read-all posture did the rest.

The fix is the one line plus a test. I deliberately did not also add the target to the credential deny-read list: the path comes from that variable alone and there is no default location to guess at, so scrubbing it closes the leak outright, and touching the deny-read builder would collide with #816 for no extra protection.