0.1.64-beta5 — restarting a loop resumes it again
Pre-release
Restarting a loop resumes it again, instead of starting the agent over on its goal.
The restart that threw the conversation away (#312)
Restarting a loop from the app started a fresh session and re-issued the /goal directive. The agent began again from its opening prompt, and everything the loop had worked out was orphaned — still on disk, no longer attached to anything.
graphcoded was innocent. The app's pane raced it, reaching the session first and creating it fresh with the opening prompt before the daemon could resume the existing one. The daemon now owns an unattended relaunch, and the pane waits for it.
Local Copilot loops hit this every time, which made it look backend-specific and sent the first round of diagnosis in the wrong direction. The real reason is narrower: nothing banks a Copilot session id locally, so there was never an id for the pane to reuse — every other backend was saved by having one, not by racing any less.
This is a regression from d8ea180, which reverted #248/#249 on 2 September.
Checking it took, on your machine
This fix is pane-side, so no build before this one can show it working — the evidence is a dial, not a log line from the old build.
After installing, restart an unattended loop and look at ~/.graphcode/dials.log. You want the new branch:
open await-daemon
Where that same pane used to log open fresh immediately after a restart.
Verified on the merged tree: 1664 tests · 175 suites · 0 failures · swiftlint 0 errors · swift-format clean. Bundle identity verified dev.graphcode.app in both the Info.plist and the code signature.
Carried forward from earlier 0.1.64 betas: loop-to-loop mail delivering again (#309/#310), the Mailroom out of the persisted graph (#308), IPC diagnostics (#303), and the daemon no longer stalling on a slow reader (#291/#301).