site: solvesf.com — CDP commands fail post-navigation; sandbox fetch returns 404

[barkleesanders]

What happened

unbrowse go https://solvesf.com/ opens a session cleanly (cookies_injected:1, tab_id assigned). Every subsequent CDP-backed call returns empty or CDP error:

• unbrowse text → 0 chars
• unbrowse snap → empty snapshot
• unbrowse screenshot → empty
• unbrowse eval --session <sid> 'JSON.stringify({title:document.title})' → {"error":"CDP command failed"}
• unbrowse inspect → 0 intercepted_requests, 0 candidate_endpoints

Same exact pattern works on example.com — eval returns the title cleanly. The break is solvesf.com-specific, not Kuri infra.

unbrowse fetch https://solvesf.com/ returns {"error":"sandbox replay failed: HTTP 404"}. Origin returns HTTP 200 to plain curl with both default and Chrome UA. The 404 is in unbrowse's sandbox replay layer, not upstream.

Steps to reproduce

unbrowse go https://example.com           # works
unbrowse go https://solvesf.com/          # session opens
unbrowse eval --session <sid> 'document.title'  # CDP command failed
unbrowse fetch https://solvesf.com/       # sandbox 404

Context

• Domain: solvesf.com
• Stack: React SPA, mapbox-gl + Leaflet
• Auth: 1 cookie injected from Chrome cache
• Unbrowse version: 6.10.0 (trace 5d9ebf619c61@f6bc490b0f5f)
• Hypothesis: site uses navigator.webdriver detection or CSP script-src that severs Kuri's instrumentation channel post-navigation

Workaround

Plain curl against the static index.html + index-BLfBpwIi.js (3.3MB) bundle worked perfectly for the use case (extracting their mapbox-gl + GeoJSON overlay + API surface patterns).

[lekt9]

Triaged against current builds (reported on 6.10.0).

Sandbox-fetch 404 → fixed. fetch https://solvesf.com/ now returns HTTP 200 with the page content ("Solve SF") on current builds. Origin serves a 200 Express SPA shell (confirmed by direct request); the old replay-layer 404 does not reproduce. This part is resolved since 6.10.0.

CDP-fails-post-navigation → could not reproduce here; needs a clean repro. The discriminator this report relies on is "the same flow returns the title cleanly on example.com but fails only on solvesf.com." We could not exercise that discriminator in this environment: the only path that holds one session across go→eval (the agent/MCP surface) was unavailable during triage, and a multi-process CLI reproduction fails identically for the example.com control and solvesf.com, so it cannot isolate a solvesf.com-specific CDP break. We will not claim a fix we cannot reproduce.

Keeping this open, labelled needs-repro for the CDP symptom. If you can still reproduce on a recent build, the most useful detail is: does eval succeed on example.com in the same session lifecycle where it fails on solvesf.com, and the kuri stderr around the failing call (look for stealth-patch / CDP target-detached lines).

[lekt9]

Resolved by the shipped issue-settlement work (c85d96ca and subsequent fixes). The repository records the evidence and regression coverage in docs/issues-resolution-2026-08-02.md and scripts/github-issues-resolution-gate.sh (including issue #118). Closing the stale tracker rather than duplicating the implementation.