feat: log proxy-blocked connections to system log via logger#216
Open
javabrett wants to merge 1 commit into
Open
feat: log proxy-blocked connections to system log via logger#216javabrett wants to merge 1 commit into
javabrett wants to merge 1 commit into
Conversation
javabrett
added a commit
to javabrett/sandbox-runtime
that referenced
this pull request
Apr 13, 2026
Adds PR anthropic-experimental#216 (unconditional stderr logging for proxy-blocked connections). Co-Authored-By: Claude Sonnet 4.6 <noreply@anthropic.com>
406bcee to
6a13981
Compare
When a network connection is blocked because its domain is not in
allowedDomains, srt previously offered no visible signal under normal
operation. Users hitting a blocked domain saw only a 403 or a failed
tool call, with no indication of which domain was responsible. SRT_DEBUG=1
was required to see anything, which is not practical in normal use.
This change adds logProxyDeny(), called from all three proxy handlers
(HTTP CONNECT, HTTP request, SOCKS), which writes blocked-connection
events to the system log via logger(1) rather than stderr:
- Avoids stderr because the srt host process shares a terminal with
the sandboxed child. stderr output interrupts TUI rendering in
applications such as Claude Code CLI.
- On macOS the message is suffixed with _SBX - the same tag srt uses
in its seatbelt deny rules - making proxy-blocks visible in the same
log stream as filesystem and mach-lookup denials:
log stream --predicate 'eventMessage ENDSWITH "_SBX"' --style compact
Example:
srt proxy-blocked: HTTPS-CONNECT api.example.com:443_SBX
- On Linux the message is written to syslog without the _SBX suffix
(which is macOS seatbelt-specific). Monitor with journalctl -f or
tail -f /var/log/syslog.
Example:
srt proxy-blocked: HTTPS-CONNECT api.example.com:443
The existing logForDebugging() call is retained alongside so SRT_DEBUG=1
users continue to see proxy-block events in the debug stream.
Co-Authored-By: Claude Sonnet 4.6 <noreply@anthropic.com>
6a13981 to
a6e16ef
Compare
javabrett
added a commit
to javabrett/sandbox-runtime
that referenced
this pull request
Apr 13, 2026
PR anthropic-experimental#216 updated: Linux support added (logger to syslog), srt-log-specific references removed from comments, PR description updated for upstream. Co-Authored-By: Claude Sonnet 4.6 <noreply@anthropic.com>
This file contains hidden or bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
Add this suggestion to a batch that can be applied as a single commit.This suggestion is invalid because no changes were made to the code.Suggestions cannot be applied while the pull request is closed.Suggestions cannot be applied while viewing a subset of changes.Only one suggestion per line can be applied in a batch.Add this suggestion to a batch that can be applied as a single commit.Applying suggestions on deleted lines is not supported.You must change the existing code in this line in order to create a valid suggestion.Outdated suggestions cannot be applied.This suggestion has been applied or marked resolved.Suggestions cannot be applied from pending reviews.Suggestions cannot be applied on multi-line comments.Suggestions cannot be applied while the pull request is queued to merge.Suggestion cannot be applied right now. Please check back later.
Problem
When a network connection is blocked because its domain is not in
allowedDomains, srt previously offered no visible signal under normal operation. Users hitting a blocked domain saw only a 403 response or an unexplained tool failure, with no indication of which domain was responsible.SRT_DEBUG=1was required to see anything, which is not practical during normal use.Solution
Add
logProxyDeny()insrc/utils/debug.ts, called from all three proxy handlers (HTTP CONNECT, HTTP request, SOCKS), which writes blocked-connection events to the system log vialogger(1)rather than stderr.Why not stderr? The srt host process shares a terminal with the sandboxed child. Any stderr output from the host interrupts TUI rendering in applications such as Claude Code CLI — the primary use case for srt.
macOS — the message is suffixed with
_SBX, the same tag srt uses in its seatbelt deny rules, making proxy-blocks visible in the same log stream as filesystem and mach-lookup denials:Example output:
Linux — the message is written to syslog without the
_SBXsuffix (which is macOS seatbelt-specific). Monitor withjournalctl -fortail -f /var/log/syslog.Example output:
The existing
logForDebugging()call is retained alongside soSRT_DEBUG=1users continue to see proxy-block events in the verbose debug stream.Changes
src/utils/debug.ts— addlogProxyDeny(protocol, hostname, port)src/sandbox/http-proxy.ts— calllogProxyDenyin CONNECT and HTTP handlers before the 403 responsesrc/sandbox/socks-proxy.ts— calllogProxyDenybefore returningfalsefromsetRulesetValidatortest/utils/debug.test.ts— new test file verifying no stderr writes andlogForDebugginggatingTest plan
bun test test/utils/debug.test.tspasses (verifies no stderr write for all three protocol values;logForDebuggingremains SRT_DEBUG-gated)allowedDomains; confirm event appears inlog stream --predicate 'eventMessage ENDSWITH "_SBX"'withoutSRT_DEBUGset[srt]output appears in the terminal of the sandboxed child processjournalctl -for/var/log/syslogSRT_DEBUG=1🤖 Generated with Claude Code