--- name: dispatch-task-kind-network-isolation description: "⭐ OPERATIONAL: for ANY git/push/gate/deploy work, launch a CODE task (start_code_task, kind:code, runs ON the machine with network+git+gh) — NOT start_task (kind:cowork), which runs in a walled sandbox with NO network to GitHub/CDN, no gh CLI, and no Playwright Chromium (so even the fast-gate boot-smoke fails). Cost a wasted session on the 2.8.5 hotfix, 2026-07-22." metadata: node_type: feedback type: feedback originSessionId: 1060dea9-0dc3-42b4-958d-2a6f7a6c0c58 modified: 2026-07-23T03:34:01.714Z --- **Incident (2026-07-22):** launched the 2.8.5-hotfix release via `start_task` (dispatch **cowork** child). It reported the sandbox is fully walled off: every HTTPS CONNECT to github.com/api.github.com/CDNs returns `403 from proxy`, no `gh` CLI, no Playwright Chromium and can't install it — and because the fast **commit** gate itself launches a headless boot-smoke (`scripts/gate.js` → `ensureChromium`), even `git commit` fails there (and `--no-verify` is prohibited). Net: a cowork task **cannot** push, gate, or deploy. Wasted the launch; had to re-route. ## THE RULE - **Code/repo/deploy work → `start_code_task`** (kind `code`). It runs on the host machine against the real filesystem (git worktree isolation), has network + git + `gh`, and CAN run the full gate and trigger `workflow_dispatch`. Every successful RobCo push/gate/deploy this era came from a `code` session. - **`start_task` (kind `cowork`) is the walled VM** — fine for sandbox compute (Python, analysis, file gen) but blocked from GitHub and the browser gate. Do NOT hand it a release. - Symptom to recognize instantly: a session reporting `403 from proxy` on GitHub or "can't install Chromium" is a cowork sandbox — it was launched with the wrong tool. ## COROLLARY — reuse an idle code session over a fresh launch `start_code_task` **timed out (180s)** on the retry; `list_sessions` confirmed nothing was created (no orphan). Per [[dispatch-session-launch-discipline]] I did NOT blind-refire. Instead routed the release to the already-idle **"Release 2.8.5 — dev to main"** code session via `send_message` — it was on the right repo, had proven push/deploy ability, and needed no launch. Reusing an idle code-session sidesteps the flaky launch path entirely; prefer it when a suitable one is idle. Related: [[dispatch-session-launch-discipline]], [[dispatch-midflight-messages-unreliable]].