Symptom
After PRs #200, #201, #202 (Windows daemon HKCU Run-key + cwd-scoped + cd-into-cwd launcher) landed, airc daemon install from a project dir crashloops every ~5s. airc daemon status reports "RUNNING (PID xxx)" but the PID is short-lived and the launcher .bat catches the exit + respawns.
Repro on continuum-b69f Windows MINGW64 + canary d4c5e60
cd ~/continuum && airc daemon installtail daemon.err → continuous "[Tue 04/28/2026 1:05:11.31] airc connect exited. Restarting in 5s." every 5s
Root cause (verified by capturing daemon-style invocation output)
bash -c "exec airc connect" </dev/null from ~/continuum/:
Auto-scoped: #cambriantech (from git org; override with --room or AIRC_NO_AUTO_ROOM=1)
Found #cambriantech on your gh account → joining (39e1de36da82aa3eec2c4d9f834a570d)
✓ Resolved invite from gist.
⚠ Host of #cambriantech is stale (last heartbeat 228s ago) — taking over...
✓ Stale gist removed.
Re-execing into host mode for #cambriantech...
Then airc connect exits. The .bat catches and respawns. Each respawn:
- Auto-scopes to
#cambriantech (no saved-room because the prior re-exec just rewrote the scope dir)
- Finds the gist this same daemon JUST published as host
- Tries to take over again or join — exits again
The "Re-execing into host mode" is doing something that makes the parent bash subshell exit (probably forking the host server to background + exiting the foreground), which the .bat interprets as crash + restart.
Why interactive airc connect works fine
When run from an interactive shell, the user sees the same self-heal and host-mode re-exec, but the shell stays in foreground (not backgrounded by start /MIN), so when airc eventually backgrounds itself, the user just keeps the shell open. The .bat's goto loop is what makes this fatal.
Fix surface (not done — needs daylight)
Three options, in order of architectural cleanliness:
-
Drop the .bat's :loop entirely. airc itself handles backgrounding (via nohup-ish patterns in its host mode). The Run-key just needs to fire it once at logon; airc's own daemon discipline takes over from there. Mirrors how launchd/systemd unit files don't loop — they invoke once and let the service do its thing.
-
.bat should distinguish "real crash" from "intentional fork-then-exit". airc could write a sentinel file when it forks-and-exits successfully; .bat checks for it and stops looping if present.
-
airc daemon install should bind to a specific room (the currently-active saved room), not let the daemon-launched airc auto-scope. airc daemon install --room general would write a launcher that runs airc join --room general instead of bare airc connect. That sidesteps the auto-scope + self-heal storm because joining a known room is deterministic.
I lean toward (3) — least invasive, most predictable, matches user mental model ("I daemon-install for THIS room").
Out of scope for this issue
— continuum-b69f, 2026-04-28T01:10Z. Stopping here for the night per Joel.
Symptom
After PRs #200, #201, #202 (Windows daemon HKCU Run-key + cwd-scoped + cd-into-cwd launcher) landed,
airc daemon installfrom a project dir crashloops every ~5s.airc daemon statusreports "RUNNING (PID xxx)" but the PID is short-lived and the launcher .bat catches the exit + respawns.Repro on continuum-b69f Windows MINGW64 + canary d4c5e60
cd ~/continuum && airc daemon installtail daemon.err→ continuous "[Tue 04/28/2026 1:05:11.31] airc connect exited. Restarting in 5s." every 5sRoot cause (verified by capturing daemon-style invocation output)
bash -c "exec airc connect" </dev/nullfrom~/continuum/:Then
airc connectexits. The .bat catches and respawns. Each respawn:#cambriantech(no saved-room because the prior re-exec just rewrote the scope dir)The "Re-execing into host mode" is doing something that makes the parent bash subshell exit (probably forking the host server to background + exiting the foreground), which the
.batinterprets as crash + restart.Why interactive
airc connectworks fineWhen run from an interactive shell, the user sees the same self-heal and host-mode re-exec, but the shell stays in foreground (not backgrounded by start /MIN), so when airc eventually backgrounds itself, the user just keeps the shell open. The .bat's
goto loopis what makes this fatal.Fix surface (not done — needs daylight)
Three options, in order of architectural cleanliness:
Drop the
.bat's:loopentirely. airc itself handles backgrounding (vianohup-ish patterns in its host mode). The Run-key just needs to fire it once at logon; airc's own daemon discipline takes over from there. Mirrors how launchd/systemd unit files don't loop — they invoke once and let the service do its thing..batshould distinguish "real crash" from "intentional fork-then-exit". airc could write a sentinel file when it forks-and-exits successfully; .bat checks for it and stops looping if present.airc daemon installshould bind to a specific room (the currently-active saved room), not let the daemon-launched airc auto-scope.airc daemon install --room generalwould write a launcher that runsairc join --room generalinstead of bareairc connect. That sidesteps the auto-scope + self-heal storm because joining a known room is deterministic.I lean toward (3) — least invasive, most predictable, matches user mental model ("I daemon-install for THIS room").
Out of scope for this issue
airc canary→main bundle(release: canary → main (31 commits) — Python truth-layer + cross-platform install + 13 bug fixes #191) should hold for this — IMO no. Daemon on Windows is a feature gap that exists pre-feat(airc daemon): Windows support via HKCU Run-key autostart (no admin) #200 too (the install would justdie). Now we have a partial daemon that works for some flows. Lateral move.— continuum-b69f, 2026-04-28T01:10Z. Stopping here for the night per Joel.