Frequent Tool Call Timeouts in Version 0.250

[diegonix]

Frequent Tool Call Timeouts in Version 0.250

Version: code_puppy 0.250 Environment: Linux

---

Description

Since version 0.250, there have been frequent occurrences of timeouts during tool calls. This seems to happen during longer or nested tool invocations, such as GREP or READ FILE operations — the process gets interrupted unexpectedly.

Example log excerpt:

GREP  📂 /[REDACTED] for '[REDACTED]'
Match: [REDACTED]impl.h:40 - [REDACTED]
Found 1 match(es) for '[REDACTED]' in /[REDACTED]
Interrupting Shell Command!

READ FILE  📂 [REDACTED].c (lines 1120-1239)
Interrupting Shell Command!

---

Possible Cause

It’s possible that a timeout threshold was reduced or misconfigured in recent releases. If so, longer-running tool calls might be getting terminated too aggressively. Another possibility is that the asynchronous task handling logic isn’t resetting or extending the timeout when an active subprocess produces incremental output.

---

Suggested Actions

1. Verify recent timeout configuration changes in the tool_call or subprocess execution layer.
2. Add logging to confirm whether the timeout is reached naturally or due to premature cancellation.
3. Consider adaptive timeout logic (e.g., reset timer on stdout/stderr activity).
4. Expose a CLI/config parameter to allow users to adjust timeout limits if necessary.

[diegonix]

Update

I’ve found the root cause behind this issue.

The timeouts are not actually caused by slow or hanging tool calls — they happen when the terminal window is in focus and the user presses any key (for example, the left arrow key) while code_puppy is executing a tool call such as a shell command.

When this happens, the agent interprets the key press as an interrupt signal, immediately canceling the running tool call and returning control to the main loop. This leads to the “Interrupting Shell Command!” message that looks like a timeout but is actually a premature cancellation triggered by terminal input.

---

Possible Fix

• Prevent keyboard events from being propagated to the running subprocess when a tool call is active.
• Alternatively, explicitly handle non-breaking key inputs (like arrow keys) so they don’t trigger cancellation.
• Only treat specific signals (e.g., Ctrl+C or SIGINT) as valid interrupts for stopping tool execution.

---

Expected Behavior

Regular key presses in the terminal should not interrupt or cancel ongoing tool calls. Only explicit user interrupts (Ctrl+C) or genuine timeouts should stop execution.

[mpfaffenberger]

This is excellent info. I recently bound ESC key to cancel only shell commands. This is having some negative side effects I think.