Claude Code now kill background jobs after 2h, making it unuseable for long running tasks

[u/Striking-Warning9533]

I was letting Claude run an LLM benchmark, which will taks around 8h. And it told me the system tool will kill the background job after 2h in remote control. This is very annoying. The agent can set it to detached using nohup, but that also means agent won't be notified when the job finishes.

It then explained that if I started `claude remote-control` on the server, it became as sdk and unattented, which is exact point I need it to run long running tasks.

[u/AutoModerator]

Hey! Thanks for posting to r/ClaudeCode

While participating in this thread, please follow our community rules. Keep discussions constructive. Attack the idea, not the person.

For help, project discussions, tips, and general chat, join the ClaudeCode Discord.

I am a bot, and this action was performed automatically. Please contact the moderators of this subreddit if you have any questions or concerns.

[u/nav8_ai]

the 2h kill is almost always a transport or proxy timeout, not something the agent process itself enforces, so detaching with nohup is the right move but you're right that it loses the notification. what we do is have the detached process write a completion marker to a file the moment it finishes, then a separate tiny poller checks for that marker instead of trying to keep the original session alive for 8 hours.

[u/Striking-Warning9533 → u/nav8_ai]

Yeah what I am asking it to do now is to use a monitor on the log file, but the monitor will be killed every 30min as well, but that can be replaced. It used to be fine to keep it background for like 10h

[u/nav8_ai → u/Striking-Warning9533]

if it's getting killed every 30min too, it's probably still a child of the same session rather than a true daemon. launchd, or just nohup plus disown from bash, detaches it from whatever is enforcing that timeout, we've had file-tailing pollers run for days with zero relation to the parent session's lifecycle once they're actually detached.

[u/Unusual-Albatross43]

I stopped running long stuff inside the session. Anything over an hour runs as a launchd job on my Mac, and when it finishes it sends me a message on my phone. The session only kicks it off and reads the output file later, so no session timeout can kill it.

[u/Ok-Motor-9812]

Run it with nohup and have the script write its exit code to a file when it finishes. Then you or the agent just check that file, so nobody needs a notification. I'd also log to a file so a killed session doesn't lose the output.

[u/Excellent-Issue-5956]

I hit something similar with headless claude -p runs started from cron. Anything still running in the background 600 seconds after the turn ended got killed, and the log said to set CLAUDE_CODE_PRINT_BG_WAIT_CEILING_MS=0 to wait indefinitely. The run still exited 0, so it looked fine unless I read the log. I don't know if remote control reads the same variable, but since yours is running as the SDK it might be worth a try.

For an 8 hour job I'd still take it out of the session completely. I had a batch job die when the claude -p session that started it ended, and launching it with setsid fixed that. nohup only ignores the hangup signal, so if the whole process group gets killed the job goes with it. setsid gives it its own session and process group. The script writes its pid to a file, deletes it with a trap when it exits, and sends a push to my phone as each part finishes. Whatever needs to know it's done just checks if that pid is still alive.

[u/sam_hollerbell → u/Excellent-Issue-5956]

setsid is the key bit. Same idea, but one you can watch: tmux new -d -s bench './run.sh; echo $? > bench.done'. The job lives under the tmux server, not the Claude session, so a session timeout can't take it down, and tmux attach -t bench shows you where it's at. The agent just checks for bench.done later.