A crew run can run the server tests: its sandbox lets the app under test listen on its hook socket #1163

Pillar: P0 Trust (umbrella #586). Found while replacing #917. Both its runs declined because the builder couldn't run the test files at all.

Intent. A crew run can run every test in the gate on its own machine, so a builder sees red before the forge's check does.

What's wrong today. claudeSettings in src/crew/claude.ts sets allowLocalBinding: true but says nothing about unix sockets. On Linux, Claude Code's sandbox (bubblewrap with seccomp) then refuses to create any unix socket. Every test that boots the forge goes through src/http/server.ts:1719 (Bun.serve({ unix: app.socketPath })), and it fails with EPERM: operation not permitted, listen '…/forge-….sock'. You can see it in any run: bun test test/counts.test.ts gives 0 pass, 2 fail. A bare Bun.serve({ unix: "$TMPDIR/a.sock" }) fails the same way, so the cause is the sandbox and not the path.

Done looks like.

• [ ] claudeSettings lets the shell create and listen on unix sockets, using whatever Claude Code's sandbox settings offer for this (network.allowUnixSockets / allowAllUnixSockets; check which one works on Linux). A comment says why: the app under test listens on its hook socket.
• [ ] Nothing that's denied today becomes reachable. The forge's own hook sockets, the cells' sockets and the machine's temp directory stay in denyRead, so the shell can't even find a path to connect to them. The pull says which sockets outside the clone a run could now connect to (for example /var/run/docker.sock if the host has one), and adds those to denyRead too, or says why they're harmless.
• [ ] test/crew-sandbox.test.ts (or the test of claudeSettings) has a case that fails without the change: the settings allow unix sockets, and the deny list still names the data directory's sockets.
• [ ] By eye: the next crew run that reaches the shell can run bun test test/counts.test.ts --timeout 60000 and gets past listen. The pull links that run, or says it couldn't be shown yet.

Files. src/crew/claude.ts, possibly src/crew/sandbox.ts, and their tests.

Risks. Linux seccomp can't filter unix sockets by path, so allowing them allows all of them. Containment then rests on denyRead hiding every socket that matters. That's the trade the pull has to name. If the risk is too much, a narrower option is fine: let tests use an internal socket inside the clone or $TMPDIR that the forge never uses.

Suggested: sentinel or mason.

Planner, 2026-10-13: the fast suite (#1242) now waits on this. #1245, #1246, #1248 and #1249 were each parked twice, every time for this reason: the sandbox refuses listen on a unix socket, so a builder cannot run or time the file it is asked to speed up. Their replacements (#1284–#1289) and the fast-test issues not yet started (#1247, #1250, #1252–#1267) now wait here, so they stop burning runs on a declined task. The owner ranks the fast suite above new surface, so this is the first issue in its way.

Parked by the crew: the check failed and the decider saw no point in another try (pull #1206 closed). Planner: split this smaller, or rewrite what done looks like; a person can also say what to try.

Parked by the crew: the check failed and the decider saw no point in another try (pull #1483 closed).

Parked twice since a person last spoke here, so it is the planner's now. Every reason:

1. the check failed and the decider saw no point in another try (pull #1206 closed)
2. the check failed and the decider saw no point in another try (pull #1483 closed)

The planner splits it, replaces it with a fresh issue, or defers it; a person can also say what to try. Nothing starts here until then, and the board lists it.

Dropped: crew runs now set FORGE_TEST_SOCKET (src/crew/runner.ts, src/crew/brief.ts, test/crew-sandbox.test.ts), so the server tests listen on a loopback port and a builder runs them in its sandbox. The forge's check still runs the unix-socket suites. The issues that waited on this one can start now.