Repository navigation
docs(serve): note the macOS Application Firewall requirement for the front door - #2792
Conversation
|
🦞👀 Pull request received. I will update this pull request when review starts. ClawSweeper review completeClawSweeper finished reviewing this revision. The review result is being finalized. |
|
Codex review: needs changes before merge. What this changesThis PR documents macOS firewall permission requirements and recovery steps for the serve SSH front door. Example: A Mac runs a local crabbox build with its firewall enabled and the serve front door on TCP port 2222.
Review scores
ProductKind: Docs · Worth it: Yes · Fix scope: Complete Merge readiness⛔ Needs changes before merge - 1 item remains Keep open: this maintainer-authored documentation follow-up addresses a real troubleshooting gap absent from main, with one narrow factual correction. Priority: P3 Before merge
Findings
Agent review detailsHow this fits togetherThe serve agent accepts remote SSH connections in the crabbox process and forwards authorized connections to container SSH endpoints on loopback. flowchart LR
Client[Remote Crabbox client] --> Firewall[macOS Application Firewall]
Firewall --> FrontDoor[Crabbox SSH front door]
Coordinator[Coordinator assignments] --> FrontDoor
FrontDoor --> Container[Container SSH on loopback]
Technical reviewBest possible solution: Keep the executable-specific firewall recovery instructions and describe local-build blocking as conditional on the host's effective firewall policy. Do we have a high-confidence way to reproduce the issue? Source confirms the process that owns the listener; the reported macOS timeout was not independently reproduced during this read-only documentation review. Is this the best way to solve the issue? The warning belongs beside the existing single-port reachability instructions, but one observed unnotarized-build failure should not become a universal firewall rule. Full review comments:
Overall correctness: patch is correct AGENTS.md: found and applied where relevant. Codex review notes: model internal, reasoning medium; reviewed against 0e9437c383e4. Provenance checked
SecurityNone. EvidenceAcceptance criteria:
What I checked:
Likely related people:
LabelsLabel changes:
Label justifications:
Rating scale6/6 🦀 challenger crab · 5/6 🦞 diamond lobster · 4/6 🐚 platinum hermit · 3/6 🦐 gold shrimp · 2/6 🦪 silver shellfish · 1/6 🧂 unranked krab. Overall follows the weaker of proof and patch quality; ✨ marks media proof (a screenshot, video, or linked artifact) that directly shows the changed behavior. WorkflowClawSweeper edits this one comment on every review. Comment Reviewed October 12, 2026, 3:13 PM ET / 19:13 UTC. |
Docs-only follow-up to #2789.
The serve SSH front door listens in the
crabboxprocess itself. On macOS hosts with the Application Firewall enabled, that binary must be allowed to accept incoming connections. Notarized release builds qualify automatically under the default "allow downloaded signed software" setting. Locally built binaries, including Developer ID-signed but unnotarized ones, are blocked silently: the agent registers and leases provision, but clients on other machines time out waiting for the SSH transport. This was found during the #2789 production live test, where Gatekeeper reported the test build as "Unnotarized Developer ID". Same-host connections are not filtered.No code, worker, or behavior changes. Verified with
node scripts/check-docs-links.mjs.