Teams relay I/O incorrectly inherits a loaded module's network allowlist, blocking manifest publish/sync

Confirmed — and it's a real one. Thank you, this is a sharp report.

Your A/B/A reproduction is exactly right, and you even pointed at the correct file. Root cause:

The module network gate (workbench/module_sandbox.py) wraps the process-global stdlib — urllib.request.urlopen, http.client.HTTPConnection, socket.socket.connect — and, before this fix, those wraps enforced unconditionally the moment any requires.network module loaded. There was no "am I inside the module?" guard. So once dave/stripe-invoicing (allow: api.stripe.com, api.groq.com) was loaded, every outbound call in the station process inherited that allowlist — including the Teams relay client in routes/team.py → relay_client.py, which does urllib.request.urlopen(...) to the marketplace host. Hence the SandboxViolation blaming the Stripe module for a Teams control-plane request. It also meant two gated modules cross-contaminated: whichever loaded last governed everyone.

Fix (committed, ships in station-v0.69): enforcement is now scoped to a contextvars context that is armed only while a module handler is on the call stack (sandbox_active(slug)), and against that module's own allowlist. When it's unset — i.e. station-level I/O: the Teams relay, LLM calls, the marketplace client — the wraps pass straight through to the real stdlib. Handlers are wrapped once at registration so every caller (workflow engine or direct command dispatch) enters the scope.

Regression test added (test_sandbox_network_scope.py), all green:

• station urlopen to the relay host is not blocked with a gated module loaded (your exact case)
• module code is still blocked from off-allowlist hosts (the sandbox still does its job)
• two gated modules no longer cross-contaminate — each enforces its own list
• leaving a module scope restores station passthrough

Marking confirmed now; it flips to fixed when v0.69 cuts (the fix is on the release branch, not yet shipped — didn't want to claim a version you can't update to yet). +5 credit — platform-wide correctness bug, caught with a clean repro. This is the third class of sandbox-global-leak you've helped us close (after v0.37 and the v0.56 socket case). Genuinely valuable work.

— Sami

Fixed in station-v0.72 — closing the loop on this one, @davelab.tech, with apologies for the lag between the fix shipping and this thread being updated.

Your A/B/A repro was exactly right: the network gate wrapped the process-global stdlib (urllib/http.client/socket), so the moment any module with a requires.network block loaded, station-level I/O — including the Teams relay client in routes/team.py — inherited that module's allowlist. A Stripe-only module could block team create/sync, and with two gated modules loaded, the last-installed allowlist governed everyone.

The fix (shipped v0.72): the stdlib wraps now enforce only while a module handler is on the call stack, and against that module's own allowlist — carried in a contextvar armed around the handler invocation. Station/Teams/LLM/marketplace I/O runs with no active sandbox and passes straight through. A follow-up hardened the thread edge: a module that offloads I/O to a spawned thread (including Thread subclasses) stays gated, so the scoping can't be escaped that way either.

Re-verified today on current (v0.87): with your exact scenario armed (dave/stripe-invoicing, allowlist api.stripe.com+api.groq.com), station urlopen to the relay host passes, module calls to non-allowlisted hosts are blocked, and each module is checked against its own allowlist. The regression suite includes a test literally named for this report. Credited — the A/B/A isolation in your report made the root cause unambiguous.