Every tool call fails with "No SW" after a macOS restart while taskwindow_status reports healthy

[pallaoro]

Summary

After a macOS restart, every browser tool call fails immediately with Error: No SW, while taskwindow_status reports everything healthy. The status check and the actual command path disagree, so a client has no signal telling it (or the user) what to do.

Environment

• Daemon 0.2.8, extension 0.2.8 (latest per taskwindow_status)
• macOS (Darwin 25.5.0), Chrome
• Called over MCP (mcp__taskwindow__*)

Reproduction

1. Use TaskWindow normally (tabs created and driven fine before the restart).
2. Restart the Mac. Chrome reopens.
3. Call tabs_create (new session, no sessionToken) → Error: No SW
4. Retry tabs_create → Error: No SW
5. Call navigate with the pre-restart sessionToken (inside browser_batch) → batch aborted at step 1 (navigate): No SW
6. Call taskwindow_status →

{
  "daemon": "running",
  "daemonVersion": "0.2.8",
  "latestVersion": "0.2.8",
  "extensionConnected": true,
  "extensionVersion": "0.2.8",
  "recovery": null,
  "update": null
}

Expected

Either the call wakes the extension's service worker and succeeds, or taskwindow_status reports the worker as not ready and returns a recovery action (for example "click the TaskWindow icon" or "reload the extension"), which is what its description promises.

Notes

• No SW does not appear in the TaskWindow source (checked at 2177835), so it looks like it surfaces from Chrome when the extension's MV3 service worker is not running or not registered after the browser restarts.
• The error text alone is not actionable for the user; a mapped message plus a recovery hint would be.

[pallaoro]

More data from the same machine, same session:

1. taskwindow doctor was fully green (daemon running, extension connected) while every tool call still failed with No SW. So doctor has the same blind spot as taskwindow_status.
2. Restarting the daemon (launchctl kickstart -k gui/$UID/com.clawnify.taskwindow) brought the daemon back on 9377, but from then on doctor reports Chrome extension not connected and the extension did not reconnect within 30 s.
3. Opening the extension's own page (chrome-extension://<id>/options/options.html) to wake the MV3 service worker did not make it reconnect either.
4. Side note: taskwindow --help ignores the flag and tries to start a second daemon, which crashes with an unhandled EADDRINUSE on 127.0.0.1:9377 when one is already running.

Suggestion: have doctor (and taskwindow_status) do a real round trip through the extension, for example a no-op command that requires the service worker, instead of trusting the socket state.

[pallaoro]

Resolved by quitting and reopening Chrome. Diagnosis from ~/.taskwindow/daemon.log, in case it helps:

• Before any restart, the log shows [bridge] extension connected (protocol 1, 0.2.8, …) immediately followed by tabs_create failed: No SW. The socket was held by an extension page (workspace/options were open) while the MV3 service worker was dead (chrome://extensions showed "service worker (Inactive)"). The page answered every command with No SW, and both doctor and taskwindow_status counted that as connected.
• After a daemon restart, nothing reconnected (waiting for the TaskWindow extension to connect); the options page sat on "Connecting…". Clicking "service worker (Inactive)" and re-pairing did not start the worker; only a full Chrome restart did.

Suggested fixes: treat a page-only connection as not connected in doctor / taskwindow_status (with a "restart Chrome" recovery hint), and have the page try to wake the worker (or reconnect through it) instead of answering No SW.