Report
A customer (Satrap) runs the daemon on a Windows machine and a Linux machine against the same tenant. Linux is smooth. On Windows:
- the daemon frequently stops working and needs a manual restart;
- after some restarts the repositories are gone and have to be re-imported;
- the user found no working way to launch a hosted agent from the CLI and fell back to instructions from ChatGPT that referenced
kcap agent, a command that no longer exists (kcap-server AI-1559 removed the last messages naming it), then launched the daemon by hand.
The hosted-agent "waiting for input while Codex is writing" symptom the same user reported is kcap-server AI-2541, fixed in server 0.11.38+ and tracked separately; nothing here assumes it is Windows-specific.
Unknowns to establish before fixing
- Windows version,
kcap --version, install method (npm global vs service install via the wrapper), and whether the daemon runs foreground, as a Windows service, or under the desktop supervisor.
- What "stops working" looks like: process gone, process alive but disconnected from the server, or connected but not advertising repos. Daemon log around the failure, and
kcap daemon status output.
- What "re-import repos" means operationally:
kcap repos add, kcap import, or re-running kcap setup. Whether the repo list is empty in the web UI, in kcap repos list, or both.
- Repository paths involved: drive letter, UNC or WSL path, junction or symlink, linked worktree.
- The exact command the user ran that failed, and its output.
Where to look
Done when
The customer's Windows daemon survives a week without manual intervention and without losing repositories, or each remaining cause has its own issue with a reproduction.
Report
A customer (Satrap) runs the daemon on a Windows machine and a Linux machine against the same tenant. Linux is smooth. On Windows:
kcap agent, a command that no longer exists (kcap-server AI-1559 removed the last messages naming it), then launched the daemon by hand.The hosted-agent "waiting for input while Codex is writing" symptom the same user reported is kcap-server AI-2541, fixed in server 0.11.38+ and tracked separately; nothing here assumes it is Windows-specific.
Unknowns to establish before fixing
kcap --version, install method (npm global vs service install via the wrapper), and whether the daemon runs foreground, as a Windows service, or under the desktop supervisor.kcap daemon statusoutput.kcap repos add,kcap import, or re-runningkcap setup. Whether the repo list is empty in the web UI, inkcap repos list, or both.Where to look
RepoPathStorepersistence and path normalization on Windows (case, drive letters, trailing separators); the advertisedrepo_pathsshape (Daemon advertises repo_paths in a shape consumers cannot match #792).Done when
The customer's Windows daemon survives a week without manual intervention and without losing repositories, or each remaining cause has its own issue with a reproduction.