[BUG] Linux sandbox: proxy UNIX sockets not visible to subprocesses (missing bind after --tmpfs /tmp)

Resolved 💬 1 comment Opened May 31, 2026 by ndl Closed Jul 4, 2026

Preflight Checklist

  • [x] I have searched existing issues and this hasn't been reported yet
  • [x] This is a single bug report (please file separate reports for different bugs)
  • [x] I am using the latest version of Claude Code

What's Wrong?

Unix sockets /tmp/claude-http-<id>.sock and /tmp/claude-socks-<id>.sock are not visible to claude => any command that tries to use them (by respecting proxy environment settings) fails at proxy CONNECT stage.

I suspect it might be related to a strict sandbox configuration (denyRead: / + denyWrite: / and then whitelisting selected directories) but not 100% sure.

The underlying reason seems to be that bwrap arglist binds /tmp/claude-http-<id>.sock and /tmp/claude-socks-<id>.sock early, then mounts --tmpfs /tmp later, which masks both binds. /tmp/claude and /tmp/claude-<UID> are re-bound after the tmpfs, but the two proxy sockets are not. Resulting connect() from the in-sandbox forwarder fails with ENOENT.

What Should Happen?

The sockets should be visible to claude => CONNECT should succeed and then result either in successful connection to the service, prompt to the user or denial - as configured in permissions.

I believe the fix should be one of the following:

  • Emit --bind /tmp/claude-{http,socks}-<id>.sock again immediately after --tmpfs /tmp, mirroring what's already done for /tmp/claude and $TMPDIR.
  • Put the sockets into $TMPDIR so that re-bind already done by claude covers sockets as well.

The work-around is to add /tmp both to allowRead and allowWrite - this exposes the sockets to claude but with the rest of host /tmp directory, which is significant security degradation.

Error Messages/Logs

Steps to Reproduce

Run claude v2.1.158 with the following sandbox config

...
"sandbox": {
    "allowUnsandboxedCommands": false,
    "autoAllowBashIfSandboxed": true,
    "enabled": true,
    "failIfUnavailable": true,
    "filesystem": {
      "allowRead": [
        "/bin",
        "/usr/bin"
        ... <anything else needed for specific project but **not** including /tmp> ...
      ],
      "denyRead": [
        "/"
      ],
      "denyWrite": [
        "/"
      ]
    },
...

Then execute curl -v https://example.com within claude and observe immediate failure at proxy CONNECT stage (= no prompts to the user as curl doesn't even reach the proxy).

Claude Model

Opus

Is this a regression?

No, this never worked

Last Working Version

Definitely didn't work in 2.1.140 either, not sure about earlier versions.

Claude Code Version

2.1.158

Platform

Anthropic API

Operating System

Other Linux

Terminal/Shell

Other

Additional Information

_No response_

View original on GitHub ↗

This issue has 1 comment on GitHub. Read the full discussion on GitHub ↗