rc.8 regression: Browser Mode still hard-breaks when configured storage-state file is missing (#2209 reproduced)

[bolichen97]

What

Reproduced live on v0.2.0-rc.8 (insider) during pre-stable validation: the playwright MCP config (playwright-config.json) referenced a contextOptions.storageState file (playwright-storage-state.json) that does not exist on disk. Every browser_* tool call failed with ENOENT before the browser context could be built — Browser Mode was completely unusable on this install.

This is the same failure mode as #2209, which was closed as completed via 501cbe2 on 2026-08-08. Since it reproduced on rc.8 on 2026-08-10, either:

1. the fix did not make the rc.8 cut, or
2. the fix only covers freshly generated configs and does not repair/validate a pre-existing config that already points at a missing storage-state file (upgrade path).

Recovery path is not user-discoverable

Getting out of this state required:

1. kirocrew browse setup to regenerate a clean config (removes the storage-state reference), and
2. killing the running playwright-mcp processes, because they cache the old config — which also kills the session's stdio MCP transport ("Transport closed" error), forcing a session restart.

No ordinary user will find this sequence. Until they do, every browser operation fails with an opaque ENOENT.

Expected

On Browser Mode startup (or config load), if the configured storage-state file is missing, either:

• seed it with an empty state ({"cookies":[],"origins":[]}), or
• drop/skip the storageState option gracefully and log a warning.

Additionally, the upgrade path should validate existing configs, not just newly generated ones.

Environment

• KiroCrew v0.2.0-rc.8 (insider channel), Linux
• Headless --config path (no Chrome extension pairing)
• Found during full RC-8 release validation (CLI/API/MCP/UI test pass)

Ask before stable

If the fix from #2209 is in the release branch, please verify it handles the pre-existing-config case; if it isn't, cherry-pick it. This hard-breaks a headline feature out of the box.

[bolichen97]

🤖 Kiro Crew Auto-Pipeline [operator: bolichen97]: Your hypothesis 2 is correct, and the code confirms it. The #2209 fix lives in generate_playwright_config() (src/kiro_crew/browser/setup.py, ~L750-759): it only attaches contextOptions.storageState when Path(storage_state).exists() at generation time. Nothing re-validates an already-written playwright-config.json, so an install whose config was generated before the fix — or generated while the storage-state file existed and later lost it — keeps a dangling storageState reference forever and every browser_* call dies with ENOENT at context creation. That is the upgrade path the fix does not cover. Scope of the automated fix: validate contextOptions.storageState on config load/startup and drop the key (or seed the file via refresh_storage_state()) when the target is missing, so a stale config self-heals instead of requiring kirocrew browse setup plus a manual playwright-mcp kill. Starting an automated fix — this issue is now claimed by bolichen97's instance.

[bolichen97]

🤖 Kiro Crew Auto-Pipeline [operator: bolichen97]

Fix PR opened: #2522

The config now self-heals at its load moment (proxy startup): a dangling contextOptions.storageState is dropped — same degrade-to-unauthenticated-context behaviour a fresh browse setup generation produces — and the repaired config is rewritten to disk so it survives restarts. One WARNING names the missing file. No process-killing or manual recovery sequence needed once this lands. Driving the PR to green now.