Summary
On Windows, worker sessions spawned via @aoagents/ao-plugin-agent-cursor exit within ~1 minute of launch (agent_process_exited, no PR, no acknowledge; lifecycle goes working → detecting → stuck), while the orchestrator session on the same host stays healthy.
Root cause is in how the cursor plugin builds the launch command for the worker path, not in the issue/task content.
getLaunchCommand() (dist/index.js) branches on whether both a systemPromptFile and a separate prompt are present:
- Worker (both present) emits, roughly:
agent … -- "$(cat <file>; printf '\n\n'; printf %s '<prompt>')" → POSIX sh syntax.
- Orchestrator (only
systemPromptFile) emits:
agent … -- "$(cat <file>)" → no printf.
On Windows, ao-core platform.js defaults the PTY shell to powershell.exe -Command (no pwsh). In PowerShell, cat (= Get-Content) and $() (subexpression) are valid, so the orchestrator branch survives. But printf does not exist in PowerShell, so the worker branch dies.
Two distinct signatures observed in the PTY:
- A:
printf : The term 'printf' is not recognized + error: unknown option '-ne' — POSIX builtin under PowerShell.
- B:
The command line is too long — the whole prompt is inlined into argv via $(cat <large-file>); for a large body (~24 KB observed) this exceeds the cmd.exe limit (~8191 chars). Independent of shell — switching to bash does not help.
This is independent of "/JSON in the GitHub Issue body: the prompt is read from a file, so its contents are literal and do not break argv.
Environment
- AO:
@aoagents/ao@0.9.x
- OS: Windows 11 (PowerShell 5.1 as PTY shell; no
pwsh)
- Plugin:
@aoagents/ao-plugin-agent-cursor
- Agent launcher:
agent / cursor-agent installed as a Windows .cmd shim
Why AO_SHELL=bash is not a sufficient workaround
platform.js exposes AO_SHELL as a PTY shell override. Setting AO_SHELL=C:\Program Files\Git\bin\bash.exe removes signature A (printf resolves), but then:
agent: command not found — Git Bash does not resolve the Windows agent.cmd launcher; and- after shimming
agent, large prompts still hit signature B (command line is too long).
So AO_SHELL=bash does not fix worker launch for non-trivial prompts.
Proposed durable fix
Deliver the worker prompt via a file or an explicit agent flag, instead of inlining it into argv with $(cat …; printf …):
- avoids POSIX
printf on Windows PowerShell (signature A), and
- avoids the argv length limit for large prompts (signature B).
A cmd.exe-style escape alone (cf. #2003 / #2006 on the code-review path) would not solve signature B, since the prompt would still be inlined into the command line.
Related
Summary
On Windows, worker sessions spawned via
@aoagents/ao-plugin-agent-cursorexit within ~1 minute of launch (agent_process_exited, no PR, no acknowledge; lifecycle goesworking → detecting → stuck), while the orchestrator session on the same host stays healthy.Root cause is in how the cursor plugin builds the launch command for the worker path, not in the issue/task content.
getLaunchCommand()(dist/index.js) branches on whether both asystemPromptFileand a separatepromptare present:agent … -- "$(cat <file>; printf '\n\n'; printf %s '<prompt>')"→ POSIX sh syntax.systemPromptFile) emits:agent … -- "$(cat <file>)"→ noprintf.On Windows,
ao-coreplatform.jsdefaults the PTY shell topowershell.exe -Command(nopwsh). In PowerShell,cat(=Get-Content) and$()(subexpression) are valid, so the orchestrator branch survives. Butprintfdoes not exist in PowerShell, so the worker branch dies.Two distinct signatures observed in the PTY:
printf : The term 'printf' is not recognized+error: unknown option '-ne'— POSIX builtin under PowerShell.The command line is too long— the whole prompt is inlined into argv via$(cat <large-file>); for a large body (~24 KB observed) this exceeds the cmd.exe limit (~8191 chars). Independent of shell — switching to bash does not help.This is independent of
"/JSON in the GitHub Issue body: the prompt is read from a file, so its contents are literal and do not break argv.Environment
@aoagents/ao@0.9.xpwsh)@aoagents/ao-plugin-agent-cursoragent/cursor-agentinstalled as a Windows.cmdshimWhy AO_SHELL=bash is not a sufficient workaround
platform.jsexposesAO_SHELLas a PTY shell override. SettingAO_SHELL=C:\Program Files\Git\bin\bash.exeremoves signature A (printfresolves), but then:agent: command not found— Git Bash does not resolve the Windowsagent.cmdlauncher; andagent, large prompts still hit signature B (command line is too long).So
AO_SHELL=bashdoes not fix worker launch for non-trivial prompts.Proposed durable fix
Deliver the worker prompt via a file or an explicit agent flag, instead of inlining it into argv with
$(cat …; printf …):printfon Windows PowerShell (signature A), andA cmd.exe-style escape alone (cf. #2003 / #2006 on the code-review path) would not solve signature B, since the prompt would still be inlined into the command line.
Related
shell: truebreaks review prompt argument passing on Windows #2003 —bug(code-review, windows): shell:true breaks review prompt argument passing— same family (Windows argument passing breaks an AO subprocess invocation), different surface/mechanism (Nodespawn→ cmd.exe word-split on the review path vs. PTY shell-stringprintf/argv on the worker launch path).shell: truebreaks review prompt argument passing on Windows #2003 (escapeArgForCmd).