@staff0rd/assist 0.286.0 → 0.288.0

package/README.md

@@ -253,9 +253,9 @@ The first backlog command in a repository that still has a local `.assist/backlo
 
 Web sessions are owned by a long-lived daemon process, not the web server: the server is a thin client that relays WebSocket traffic to the daemon over a local IPC socket (unix domain socket at `~/.assist/daemon/daemon.sock`; named pipe `\\.\pipe\assist-sessions-daemon` on Windows). Restarting the web server leaves sessions running with scrollback intact. The daemon logs to `~/.assist/daemon/daemon.log` (timestamped lines tagged with the daemon's pid, including why it spawned and which sessions it restored) and auto-exits once no sessions remain and no client has been connected for 60 seconds (it is respawned on demand by the web server). Daemon spawning is arbitrated by an `O_EXCL` lockfile so racing clients start at most one daemon; sessions are only restored after the daemon owns the IPC socket, and a daemon that loses ownership of `daemon.pid` shuts down its sessions and exits rather than running orphaned.
 
-Set `sessions.windowsProjectsRoot` in config to the Windows `.claude/projects` directory as seen from WSL (e.g. `/mnt/c/Users/<user>/.claude/projects`) to surface Windows-host repos in the selector. Their transcripts are discovered alongside local ones and tagged as windows-origin (the project name is derived with Windows path rules so `C:\…` cwds name correctly).
-
-Selecting a windows-origin repo (cwd like `C:\…`) from the WSL UI runs an interactive session natively on Windows: the WSL daemon launches a second assist daemon on the Windows host on demand via interop (`cmd.exe /c start "" assist daemon run`), connects to it over TCP (the WSL daemon cannot reach the Windows named pipe directly), and proxies create/resume and I/O to the Windows daemon's native PTY. Windows sessions appear in the same list as local ones (their ids are namespaced internally to avoid collisions) with live output, scrollback, and resume. The TCP connection performs a version handshake on connect; a mismatch is logged (auto-healing comes later). A native Windows daemon listens for the WSL bridge on `sessions.windowsDaemonPort` (default `51764`); the WSL daemon dials `sessions.windowsDaemonHost` (default `127.0.0.1`, which works under WSL2 mirrored networking — NAT-mode setups should set it to the Windows host IP).
+From WSL, the selector can also surface and drive Windows-host repos (requires `assist` installed on the Windows host). Config keys:
+- `sessions.windowsProjectsRoot` — the Windows `.claude/projects` directory as seen from WSL (e.g. `/mnt/c/Users/<user>/.claude/projects`); enables discovery of Windows-host repos, tagged with a `Windows` badge. Selecting one launches a native assist daemon on Windows and runs an interactive session there.
+- `sessions.windowsDaemonHost` / `sessions.windowsDaemonPort` — where the WSL daemon reaches the native Windows daemon (defaults `127.0.0.1` / `51764`; set the host to the Windows IP on WSL2 NAT-mode networking).
 
 When iterating on assist itself: web server changes only need the `assist sessions` process restarted — sessions survive. Daemon/session-core changes need `assist daemon restart` to load the new code; this kills the PTYs, then claude sessions — including assist sessions that wrap claude, like `assist draft` — are auto-respawned via `claude --resume` with scrollback starting fresh, while run sessions (and assist sessions whose claude sessionId was never discovered) reappear as not-restored tiles that can be retried.
 - `assist next [id] [--once]` - Alias for `backlog next [id]`; `--once` exits after the first completed item run instead of prompting for another