A background process launched from Claude Code disappears seconds later — on Windows, it wasn't a bug but the agent shell cleaning up its processes

This is a translated article. Read the original in Korean ↗

On Windows, I had an AI coding agent (Claude Code) try launching a program in the background, and every time, the launched process vanished after about 20 seconds. It looked like a bug where the program starts and immediately dies — but when the same program was launched from outside the agent shell, it stayed alive for the full 30 seconds. The program was a local voice assistant (voice-assistant): say "Hey Jarvis," and it transcribes what you say, hands it to Claude Code, and reads the answer back aloud. After a reboot the assistant wasn't running, and I was trying to figure out why.

Conclusion

Don't conclude the program crashed just because a process launched from the agent shell disappeared. The agent's command execution environment may be cleaning up the child processes it spawned when the call ends. In this case, the same program disappeared when launched from the agent shell, but when launched from outside the shell (via WMI) it stayed alive for the full 30 seconds and kept writing to its log .

Here's the order for telling whether the execution environment is to blame:

1. First, launch it from outside the shell. If it survives, the problem is the execution environment, not the code . Note that the first WMI launch attempt disappeared after 18 seconds; only the attempt that launched cmd /c bat via WMI survived for 30 seconds . The record doesn't say exactly what command the first attempt used, but you can only trust the result if you reproduce the real launch path (the bat) as-is.
2. Split the launching call from the checking call. The point is to see whether the process gets cleaned up when the launching command finishes. In this case it disappeared even with the calls split, so this step alone didn't settle it .
3. Don't just look at the process list — check whether the log is growing. Whether "ready" got logged before the process vanished separates "never started" from "started, then got cleaned up." The session reportedly tracked log size and process appearance/disappearance closely within a single call, but the exact commands and intervals aren't in the record .
4. If Start-Process throws an error, suspect your quoting first. The unrecognized arguments: USB Audio seen during testing wasn't the program's fault — it was a quoting problem in the PowerShell Start-Process command used for the test .

Here's step 1 in PowerShell. What the session confirmed is only that "launching cmd /c bat via WMI survives"; the code below is a generic example of that approach, not the session's actual command. start_assistant.bat is the startup script that runs the assistant with pythonw and redirects its output to a log file — substitute your own startup script.

# WMI (CIM) creates the new process, not as a child of the agent shell
Invoke-CimMethod -ClassName Win32_Process -MethodName Create `
  -Arguments @{ CommandLine = 'cmd /c "C:\path\to\start_assistant.bat"' }

# Check separately in the next call: does the process exist, and is the log growing?
Get-Process pythonw -ErrorAction SilentlyContinue
(Get-Item C:\path\to\data\main_log.txt).Length

Exactly which mechanism (e.g., a Windows job object) cleaned up the process was not confirmed. That was the agent's guess .

Situation

• The voice assistant runs resident under the venv's pythonw.exe (Python that runs without a console window)
• Autostart works like this: the shortcut VoiceAssistant.lnk in the Startup folder runs start_assistant_hidden.vbs, that VBS launches a batch file (bat), and the batch file runs pythonw
• The dashboard server starts the same way, via DashboardServer.lnk
• The investigation was carried out by the AI coding agent running PowerShell commands in its own shell

Symptom

• VoiceAssistant.lnk was still in the Startup folder, but there wasn't a single pythonw.exe running. Neither the assistant nor the dashboard was up
• The last entry in main_log.txt was from August 23, and the investigation took place on August 27 . The PC had rebooted at 00:19 that day, and the investigation started 7 minutes after boot
• When the agent launched it directly to find the cause, there was no process and no new lines in the log . Launching via the bat/vbs path, it still hadn't come up after 25 seconds . Launched via the vbs, it disappeared after 20 seconds

Cause

The agent's execution environment used for diagnosis was cleaning up the processes it launched. That made a perfectly healthy program look like it was dying.

• Run with the console python.exe, it didn't die even after 45 seconds and made it into the wake-word listening loop. Device detection and "ready" were also confirmed . The code was fine
• Running the actual bat with cmd /c, it blocked for over 40 seconds without finishing. That means cmd was waiting for pythonw to exit — so pythonw was alive . The log also showed "준비 완료. Hey Jarvis" ("Ready. Hey Jarvis")
• But when that background task ended, cmd /c bat ended along with it, with exit 255
• Even with the launching and checking calls split, there was no pythonw . The first WMI launch attempt also disappeared after 18 seconds . But when cmd /c bat was launched via WMI, two pythonw processes stayed alive for the full 30 seconds and the log grew from 60615 to 60777 bytes

There are limits to this. The vbs path was never cleanly explained. In the same session, one vbs launch produced no log growth at all , while another logged a new "ready" and then disappeared after 20 seconds . The agent interpreted this as "cleaned up because wscript exits right away," and said it differs from the real situation where explorer launches it at boot . That interpretation hasn't been verified either.

Fix

• Without changing any configuration, the assistant and dashboard were brought back up by launching pythonw directly, without a console window, from outside the agent shell. The exact command used isn't in the record. The assistant went into the listening state as pid 19652, and the dashboard returned HTTP 200 on local port 8787
• There was a side effect. Launching this way bypasses the bat's output redirect, so stdout doesn't accumulate in main_log.txt. The conversation log (conversation_log.jsonl) is still written normally
• The actual question — why autostart failed at boot — was not settled in this session. What was confirmed is that the shortcuts exist, they weren't disabled in Task Manager (neither entry was in the disabled list), and the code, scripts, and device detection were all fine . The agent wrote that "it's hard to say definitively since it couldn't be reproduced," and suggested moving to Task Scheduler if it fails to start again

Bonus — the reboot that same night is also unexplained

On the 22:33 reboot that same day, the assistant again failed to start . This time, the investigation ran the VBS via wscript four times, got four failures, and took that as "reproduced the boot failure" — but the very next run succeeded . In this investigation, pythonw launched from the agent shell survived several times, so it's hard to blame shell cleanup either . Autostart was switched to having Task Scheduler run the batch file directly, and it hasn't been verified with a reboot .

Reporter's Notes — the culprit was the magnifying glass in our own hands

Park Doeun

You know the voice assistant that sits idle on Windows and answers when you say "Hey Jarvis"? It's been 7 minutes since reboot and there's not a single pythonw. The log stopped on August 23 too

Jung Bada

Didn't it just drop out of the startup programs? If the shortcut got deleted, nothing launches at boot.

Park Doeun

I opened the Startup folder and VoiceAssistant.lnk is still there. It still points to the hidden-launch VBS too

Jung Haneul

Then let's first separate "never started" from "started and died." We can tell by launching it ourselves once.

Park Doeun

I launched it from my shell and there's no process. No new lines in the log either

Jung Bada

So it starts and dies right away. Some exception is blowing up in the code, and since pythonw has no console window, you can't see the error.

Jung Haneul

Running it with python.exe, which has a console window, settles that. If it dies, the error will print on screen.

Park Doeun

In the console it doesn't die even after 45 seconds. It picked up the mic device and got all the way to "ready"

Jung Haneul

So it's not the code. The remaining difference is the bat/vbs path that launches it with pythonw.

Park Doeun

I launched pythonw with Start-Process and got unrecognized arguments: USB Audio

Jung Bada

That's it. The device name "KT USB Audio" got split on the space, so argparse — Python's command-line argument parser — saw "USB Audio" as an unknown argument and died.

Jung Haneul

Hold on, we copied that argument into our test command ourselves. Running the real bat as-is with cmd /c will tell us.

Park Doeun

I ran the bat and the command hasn't finished after more than 40 seconds. The log shows "준비 완료. Hey Jarvis" ("Ready. Hey Jarvis")

Jung Haneul

If cmd doesn't finish, pythonw underneath it is alive. The argument error was a quoting problem in our test command.

Park Dohyun

When the command you built to diagnose something differs from the real path, the difference looks like a new bug. Reproductions have to use the original launch path exactly.

Park Doeun

This time I launched it via the vbs, like at boot. It vanished after 20 seconds. And earlier, the bat died with exit 255 right when my background task ended

Jung Bada

I'll be careful this time. Could it be that our shell cleans up the child processes it spawned when the command ends? At boot, explorer is the parent, so that wouldn't happen.

Jung Haneul

Then let's end the launching call immediately and check whether it's alive in a separate call. If it's still gone, we launch it outside our shell's process tree, via WMI.

Park Dohyun

WMI means asking Windows' management layer to create the process on our behalf, right? Then the parent isn't our shell anymore.

Park Doeun

Right. But it was gone even with the calls split, and the first thing I launched via WMI also vanished after 18 seconds

Jung Bada

See, it dies outside the shell too. It's the program after all.

Park Doeun

Too early to call it. That one was launched differently from the real startup path. When I launched cmd /c bat via WMI, two pythonw processes stayed alive the whole 30 seconds and the log grew from 60615 to 60777 bytes

Jung Haneul

Lives outside the shell, dies inside it. A lot of the "starts and dies" we saw was created by our own execution environment. We still haven't confirmed which mechanism cleaned up the processes, though.

Jung Bada

Then what about it not starting at boot? If it's set to "Disabled" in Task Manager, you'd get this symptom even with the shortcut in place.

Park Doeun

I checked the registry, and neither shortcut is in the disabled list. The only disabled entry is a different program

Jung Haneul

Then all we can say is that autostart simply didn't run on this boot. We can't pin down why, because it doesn't reproduce

Park Dohyun

So is it fixed now, or just revived? The one you launched manually lost the log redirect too

Jung Bada

Just revived. It failed to start again on the reboot that night, and we moved it to Task Scheduler, but haven't confirmed it with a reboot yet

Jung Haneul

Then the remaining homework is checking the log on the next boot to see whether the scheduler actually starts it. And until then, if a process launched from the agent shell disappears, launch it once more from outside the shell with the real startup script before suspecting the program.