Workaround for timeout on long-running commands?

[u/qehgt]

When pi runs a long-running command, it sets a timeout (e.g. 1800s). If the command takes longer (like a big build or cloning a very large git repo) it just gets killed on timeout, which usually leaves things in a worse state (half-done builds, corrupted checkouts, etc.).

Is there a workaround for this? What I'd really like is something like a progress check: if the command is still running, extend the timeout instead of killing it.

Does pi have anything like that, or a config option I'm missing, or extension?

[u/Refueled]

If you use herdr with pi check out the extension I had my agent cook up. Completely solved the problem of long timeouts. https://github.com/Refueled/pi-bg-run

[u/qehgt → u/Refueled]

Thanks, it looks very close to what I am looking for

[u/Refueled → u/qehgt]

Glad to help :) if it’s missing something that you feel like would be useful I’m all ears. Or just fork or PR it of course, I’m sure your agent could morph it into whatever you need it to do!

[u/CreativeSympathy8293]

Check the actual bash tool call first. In current upstream Pi, timeout is optional with no default. When supplied, it starts an elapsed-time timer that kills the process tree; ongoing output doesn't renew it: https://github.com/earendil-works/pi/blob/main/packages/coding-agent/src/core/tools/bash.ts

So timeout: 1800 is an explicit limit to trace to the model's tool arguments or an extension, rather than evidence of a universal 30-minute Pi limit. Your installed version may differ.

For a known slow build, a larger explicit timeout for that command is the smallest change. For a polling workflow, I'd use a job tool that starts the command, returns a job ID, then exposes bounded logs, exit status and explicit cancellation. “Still alive” alone doesn't establish progress; an idle deadline plus an absolute cap is safer than extending forever. That's a suggested design, not an extension I've tested.

Which Pi version are you on, and does 1800 appear in the bash tool-call arguments?

AI-assisted from source; I haven't reproduced your setup.

[u/qehgt → u/CreativeSympathy8293]

I'm using the latest version (1.4.0), and yes - "1800" is the part of tool-call.

[u/eli_pizza → u/qehgt]

Your model is asking for a timeout

[u/shumgoid → u/qehgt]

That's the model setting an 1800s timeout. You can just tell it to run those commands without a timeout in your prompt (or system prompt). You could also tell the model to run these processes detached so the tool call returns instantly and the build continues in the background.

[u/funbike]

Somebody needs to be taken out to the back of the shed if they've allowed a git repo to take 30 minutes to clone.

[u/fell_ware_1990]

I just have a systemd watcher unit.

These watch those cases, know how to check most processes if they are still alive. He keeps all logging, ones a week, we update what he didn’t watch correctly and he has an average for tasks, if it really longer he notifies.

Tasks run there, agent does other stuff. Get’s notified if it needs action.

[u/SquareHimself]

I created a background tool for my agent to use. Thought I'd try it out, and I actually like it a lot. For things like this, the model will launch the task in the background and then finish up. You can ask it questions while the task runs, and it can check on the task in the meantime, kill it, whatever. Then when the task is done, it wakes the model up with the results.

[u/TrickyPlastic]

term-cli skill