[BUG] Windows Task Scheduler silently fails to launch `claude -p` subprocess (no process, no output, stuck "Running" status)

Preflight Checklist

• [x] I have searched existing issues and this hasn't been reported yet
• [x] This is a single bug report (please file separate reports for different bugs)
• [x] I am using the latest version of Claude Code

What's Wrong?

Related to #95966 (same class of problem - unattended/scheduled invocations of Claude Code silently not completing - but a different scheduler and likely a different mechanism, so filing separately).

We tried working around the in-app scheduled-tasks bug by triggering claude -p from a native OS scheduler (Windows Task Scheduler) instead. The wrapper script works correctly and reliably when run directly (verified twice, clean exit, ~2 minutes each, correct output). The exact same script, triggered by a Windows Task Scheduler entry that runs python.exe wrapper.py (which in turn shells out to claude.exe -p ... via subprocess), produced across 3 separate attempts:

• No log output at all (the wrapper writes a log line unconditionally, even on error/timeout)
• No python.exe or claude.exe process observable via Get-Process at any point we checked
• Task Scheduler's own status (Get-ScheduledTaskInfo / schtasks /query) continued reporting "Running" long after no such process existed - a false-status signature, not just a slow task

We ruled out:

• Working directory defaulting to System32 (explicitly set -WorkingDirectory, no change)
• Our own script-level timeout racing Task Scheduler's ExecutionTimeLimit (widened the separation, no change)

Not yet confirmed, but our leading hypothesis: claude.exe may behave differently (hang or fail silently) when launched as a child process with no interactive console/window-station attached, which is exactly the environment Task Scheduler provides by default. A plain Python script (no claude involved) scheduled the same way works reliably for us, which is what points the suspicion at claude.exe specifically rather than at Task Scheduler in general.

Environment: Windows 11, Claude Code Desktop app, claude.exe also used standalone via CLI (claude -p ...) which works fine when invoked interactively or from an already-running process.

Happy to share the wrapper script and exact repro steps if useful.

What Should Happen?

A scheduled task that shells out to claude -p should either run to completion the same way it does when invoked directly (writing output, exiting cleanly), or fail loudly/quickly with a real error - not silently produce no process and no output while Task Scheduler's own status continues to claim it is running.

Error Messages/Logs

Steps to Reproduce

1. Write a small Python wrapper script that shells out to claude -p --output-format text (or similar), writing a log line to a file both on success and inside every exception/timeout handler.
2. Confirm it works by running it directly: python wrapper.py - completes cleanly, log file gets written, correct output.
3. Register a Windows Task Scheduler task whose action is python.exe "wrapper.py", with an explicit -WorkingDirectory set to the project folder (not left blank/defaulting to System32).
4. Trigger it with Start-ScheduledTask -TaskName "...".
5. Observe: Get-ScheduledTaskInfo reports the task as "Running" (LastTaskResult stays at the "running" placeholder value) for well beyond any reasonable duration.
6. Check for a live process: Get-Process -Name "python*" and Get-Process -Name "claude*" both return nothing - no process is actually running.
7. Check the log file the wrapper unconditionally writes to: it does not exist, or has no new entry for this run.

Repeated 3 separate times, same result each time. The identical wrapper script run directly (step 2) has never failed.

Claude Model

None

Is this a regression?

I don't know

Last Working Version

_No response_

Claude Code Version

2.1.281 (Claude Code)

Platform

Other

Operating System

Windows

Terminal/Shell

PowerShell

Additional Information

Auth: subscription login via claude.ai (Claude Code desktop app), not a direct ANTHROPIC_API_KEY - marked "Other" above since that's more accurate than "Anthropic API" for this setup.

This is a second, independent data point related to #95966 (same underlying class of "unattended Claude Code invocation silently doesn't complete"), but a different scheduler and likely a different specific cause, so filed separately rather than as a comment there.