anomalyco/opencode
1
0
Fork 0
mirror of https://github.com/anomalyco/opencode.git synced 2026-07-22 02:05:26 -04:00
Code Issues 5.9k Packages Projects Releases 19 Wiki Activity

Bash tool does not show time out to model or user, model might set time out incorrectly #1965

New Issue
Open
opened 2026-02-16 17:33:28 -05:00 by yindo · 14 comments
yindo commented 2026-02-16 17:33:28 -05:00
Owner
Copy Link
Copy Source

Originally created by @TheFibonacciEffect on GitHub (Oct 5, 2025).

Originally assigned to: @rekram1-node on GitHub.

As far as I can tell the bash tool does not notify the model, when the execution is finished and the model can not tell the exit condition of the command that has been ran. It will only wait for a couple of seconds and then assume that that is all the output that the program gave. Any output that came afterwards is never passed on to the model.

To Reproduce:

Model used: GPT-4o

Prompt:

run the program using ./program.sh and tell me the result, dont read the file

program.sh file

#! /bin/bash
sleep 100
echo "the code failed" >&2
exit 1

Screenshot:

Image

Motivation / Use case

I aim to use these models for tedious jobs in high performance computing. Often times programs take a long time to compile and run and then fail because of minor issues and missconfigurations. Having an llm fix these minor issues so that there is no need for a human to wait until the job is finally executed and crashed just to fix minor things would be very nice.

Originally created by @TheFibonacciEffect on GitHub (Oct 5, 2025). Originally assigned to: @rekram1-node on GitHub. As far as I can tell the bash tool does not notify the model, when the execution is finished and the model can not tell the exit condition of the command that has been ran. It will only wait for a couple of seconds and then assume that that is all the output that the program gave. Any output that came afterwards is never passed on to the model. # To Reproduce: Model used: GPT-4o Prompt: ``` run the program using ./program.sh and tell me the result, dont read the file ``` program.sh file ``` #! /bin/bash sleep 100 echo "the code failed" >&2 exit 1 ``` Screenshot: <img width="1317" height="922" alt="Image" src="https://github.com/user-attachments/assets/8abce698-1146-43a8-b353-ea44c4dfeef9" /> # Motivation / Use case I aim to use these models for tedious jobs in high performance computing. Often times programs take a long time to compile and run and then fail because of minor issues and missconfigurations. Having an llm fix these minor issues so that there is no need for a human to wait until the job is finally executed and crashed just to fix minor things would be very nice.
yindo commented 2026-02-16 17:33:28 -05:00
Author
Owner
Copy Link
Copy Source

@github-actions[bot] commented on GitHub (Oct 5, 2025):

This issue might be a duplicate of existing issues. Please check:

  • #1721: Reports that the bash tool often times out and suggests making the default timeout longer or infinite, as builds/commands can take more than 2 minutes to complete
  • #731: Comprehensive analysis of stability issues including 'Process Management Gaps' where non-terminating processes make TUI unresponsive and missing stdin handling causes command deadlocks
  • #652: Documents how the bash tool becomes unresponsive with commands requiring interaction (sudo passwords), with analysis of the Bun.spawn implementation lacking stdin handling
  • #1970: Feature request for background bash execution to handle long-running processes without blocking the session
  • #2124: Request for ability to kill currently executing bash commands (closed but relevant)

Your issue about commands not finishing/waiting long enough appears to be the same core problem described in these issues - the bash tool has timeout limitations and doesn't properly handle long-running or async processes.

Feel free to ignore if none of these address your specific case.

@github-actions[bot] commented on GitHub (Oct 5, 2025): This issue might be a duplicate of existing issues. Please check: - #1721: Reports that the bash tool often times out and suggests making the default timeout longer or infinite, as builds/commands can take more than 2 minutes to complete - #731: Comprehensive analysis of stability issues including 'Process Management Gaps' where non-terminating processes make TUI unresponsive and missing stdin handling causes command deadlocks - #652: Documents how the bash tool becomes unresponsive with commands requiring interaction (sudo passwords), with analysis of the Bun.spawn implementation lacking stdin handling - #1970: Feature request for background bash execution to handle long-running processes without blocking the session - #2124: Request for ability to kill currently executing bash commands (closed but relevant) Your issue about commands not finishing/waiting long enough appears to be the same core problem described in these issues - the bash tool has timeout limitations and doesn't properly handle long-running or async processes. Feel free to ignore if none of these address your specific case.
yindo commented 2026-02-16 17:33:28 -05:00
Author
Owner
Copy Link
Copy Source

@rekram1-node commented on GitHub (Oct 6, 2025):

@TheFibonacciEffect maybe we aren't showing the timeout properly (if the command doesnt finish within timeout) but if I do this I see it run as expected, note that the llm passes a timeout value in ms to the script

@rekram1-node commented on GitHub (Oct 6, 2025): @TheFibonacciEffect maybe we aren't showing the timeout properly (if the command doesnt finish within timeout) but if I do this I see it run as expected, note that the llm passes a timeout value in ms to the script
yindo commented 2026-02-16 17:33:28 -05:00
Author
Owner
Copy Link
Copy Source

@TheFibonacciEffect commented on GitHub (Oct 6, 2025):

@rekram1-node Can I force the LLM to wait until the command completes?

Strange that you cant reproduce it, because I tried different, similar things and it never seemed to have waited correctly. Maybe it did look at the file in your case to find the correct estimate of the time to wait? What if you set the sleep to 10000 seconds? How would it know how long a command takes to execute?

@TheFibonacciEffect commented on GitHub (Oct 6, 2025): @rekram1-node Can I force the LLM to wait until the command completes? Strange that you cant reproduce it, because I tried different, similar things and it never seemed to have waited correctly. Maybe it did look at the file in your case to find the correct estimate of the time to wait? What if you set the sleep to 10000 seconds? How would it know how long a command takes to execute?
yindo commented 2026-02-16 17:33:28 -05:00
Author
Owner
Copy Link
Copy Source

@rekram1-node commented on GitHub (Oct 6, 2025):

@TheFibonacciEffect the main idea behind the timeout is to prevent the llm from calling commands that could permanently block the loop, the llm generally reads files before running them so generally it gets a decent idea of what timeout to set.

Now you may get different results depending on intelligence of your model etc but generally I dont have issues with this

@rekram1-node commented on GitHub (Oct 6, 2025): @TheFibonacciEffect the main idea behind the timeout is to prevent the llm from calling commands that could permanently block the loop, the llm generally reads files before running them so generally it gets a decent idea of what timeout to set. Now you may get different results depending on intelligence of your model etc but generally I dont have issues with this
yindo commented 2026-02-16 17:33:28 -05:00
Author
Owner
Copy Link
Copy Source

@TheFibonacciEffect commented on GitHub (Oct 6, 2025):

@rekram1-node Okay, did you run it with the same model?

Because even if I tell it how long to wait, it doesnt do it.

Image
@TheFibonacciEffect commented on GitHub (Oct 6, 2025): @rekram1-node Okay, did you run it with the same model? Because even if I tell it how long to wait, it doesnt do it. <img width="1318" height="640" alt="Image" src="https://github.com/user-attachments/assets/048244d5-6819-4c53-93b9-7987d665e10d" />
yindo commented 2026-02-16 17:33:28 -05:00
Author
Owner
Copy Link
Copy Source

@TheFibonacciEffect commented on GitHub (Oct 6, 2025):

So to me it is unclear how it could ever set the timeout correcly. Benchmarking programs to estimate how long a process takes is generally non trivial and I am not positive that an LLM can just do it and come up with correct estimations for runtimes just form inspecting the code.

llm generally reads files before running them

Thats why my prompt included that it should not read the file (in order to actually be realistic, because if my program imports 100 things, it can not know how long these imports will take).
Did you actually use the provided prompt when trying to reproduce the issue?

@TheFibonacciEffect commented on GitHub (Oct 6, 2025): So to me it is unclear how it could ever set the timeout correcly. Benchmarking programs to estimate how long a process takes is generally non trivial and I am not positive that an LLM can just do it and come up with correct estimations for runtimes just form inspecting the code. > llm generally reads files before running them Thats why my prompt included that it should not read the file (in order to actually be realistic, because if my program imports 100 things, it can not know how long these imports will take). Did you actually use the provided prompt when trying to reproduce the issue?
yindo commented 2026-02-16 17:33:28 -05:00
Author
Owner
Copy Link
Copy Source

@TheFibonacciEffect commented on GitHub (Oct 6, 2025):

And it appears to me at least, that the LLM does not get notified in case the command times out. That would be useful information to pass on.

@TheFibonacciEffect commented on GitHub (Oct 6, 2025): And it appears to me at least, that the LLM does not get notified in case the command times out. That would be useful information to pass on.
yindo commented 2026-02-16 17:33:28 -05:00
Author
Owner
Copy Link
Copy Source

@rekram1-node commented on GitHub (Oct 6, 2025):

And it appears to me at least, that the LLM does not get notified in case the command times out. That would be useful information to pass on.

Totally agree

@rekram1-node commented on GitHub (Oct 6, 2025): > And it appears to me at least, that the LLM does not get notified in case the command times out. That would be useful information to pass on. Totally agree
yindo commented 2026-02-16 17:33:28 -05:00
Author
Owner
Copy Link
Copy Source

@rekram1-node commented on GitHub (Oct 6, 2025):

Did you actually use the provided prompt when trying to reproduce the issue?

Fair i didn't see that part my bad lol

@rekram1-node commented on GitHub (Oct 6, 2025): > Did you actually use the provided prompt when trying to reproduce the issue? Fair i didn't see that part my bad lol
yindo commented 2026-02-16 17:33:28 -05:00
Author
Owner
Copy Link
Copy Source

@rekram1-node commented on GitHub (Oct 6, 2025):

So if we fixed that part where the timeout "error" isn't showing to the llm, would that address this for you? Just wanna make sure I undersstand all your asks.

Just to clarify:

bash tool executes asynchronously without reporting back

This is incorrect^ it is awaited, we just don't render the timeout anywhere or present it to llm BUT we should

@rekram1-node commented on GitHub (Oct 6, 2025): So if we fixed that part where the timeout "error" isn't showing to the llm, would that address this for you? Just wanna make sure I undersstand all your asks. Just to clarify: > bash tool executes asynchronously without reporting back This is incorrect^ it is awaited, we just don't render the timeout anywhere or present it to llm BUT we should
yindo commented 2026-02-16 17:33:28 -05:00
Author
Owner
Copy Link
Copy Source

@rekram1-node commented on GitHub (Oct 6, 2025):

Just merged this: https://github.com/sst/opencode/pull/2986/files

@TheFibonacciEffect lmk what you think

Ex:

script.sh:

#! /bin/bash
echo "running script"
sleep 100
echo "the code failed" >&2
exit 1

Me: run ./script.sh with timeout of 1s, dont read file

LLM calls tool:


Shell Runs script.sh with 1 second timeout

$ ./script.sh
running script


(Command timed out after 1000 ms)
@rekram1-node commented on GitHub (Oct 6, 2025): Just merged this: https://github.com/sst/opencode/pull/2986/files @TheFibonacciEffect lmk what you think Ex: script.sh: ``` #! /bin/bash echo "running script" sleep 100 echo "the code failed" >&2 exit 1 ``` Me: run ./script.sh with timeout of 1s, dont read file LLM calls tool: ``` Shell Runs script.sh with 1 second timeout $ ./script.sh running script (Command timed out after 1000 ms) ```
yindo commented 2026-02-16 17:33:28 -05:00
Author
Owner
Copy Link
Copy Source

@TheFibonacciEffect commented on GitHub (Oct 6, 2025):

@rekram1-node
only partially.
To me there are two ways to address this issue:

  1. Present the LLM and the user with timeout and exit condition of bash commands (I think what you did looks great)
  2. (Optional but preferred) Have a setting that timeouts are ignored and the LLM doesn't need to provide an estimate

I would prefer something like the second, because I would believe that the estimated runtime might be close, but inaccurate, leading to the run to take multiple attempts. Also the time for the command might be longer than MAX_TIMEOUT which is currently set to the very low time of 10 minutes. I frequently have to debug programs that take 10 minutes just to compile, start and crash because of some stupid mistake. Or I might train an ML model and the optimization takes 10 minutes on the small model.

Thanks a lot 😄

@TheFibonacciEffect commented on GitHub (Oct 6, 2025): @rekram1-node only partially. To me there are two ways to address this issue: 1. Present the LLM and the user with timeout and exit condition of bash commands (I think what you did looks great) 2. (Optional but preferred) Have a setting that timeouts are ignored and the LLM doesn't need to provide an estimate I would prefer something like the second, because I would believe that the estimated runtime might be close, but inaccurate, leading to the run to take multiple attempts. Also the time for the command might be longer than MAX_TIMEOUT which is currently set to the very low time of 10 minutes. I frequently have to debug programs that take 10 minutes just to compile, start and crash because of some stupid mistake. Or I might train an ML model and the optimization takes 10 minutes on the small model. Thanks a lot 😄
yindo commented 2026-02-16 17:33:28 -05:00
Author
Owner
Copy Link
Copy Source

@rekram1-node commented on GitHub (Oct 6, 2025):

setting is worth considering but have you tried just doing shell invocations by typing:

! into prompt input and then just typing your script invocation? there is no timeout if you are the one executing it

@rekram1-node commented on GitHub (Oct 6, 2025): setting is worth considering but have you tried just doing shell invocations by typing: ! into prompt input and then just typing your script invocation? there is no timeout if you are the one executing it
yindo commented 2026-02-16 17:33:28 -05:00
Author
Owner
Copy Link
Copy Source

@TheFibonacciEffect commented on GitHub (Oct 6, 2025):

Hi thats a good workaround for now, thanks a lot. I think I would prefer a setting, because of the usecase discussed before, but its still useful.

@TheFibonacciEffect commented on GitHub (Oct 6, 2025): Hi thats a good workaround for now, thanks a lot. I think I would prefer a setting, because of the usecase discussed before, but its still useful.
Sign in to join this conversation.
No Branch/Tag Specified
Branches Tags
Labels
Clear labels
acp
bad
bug
discussion
docs
documentation
enhancement
extension
good first issue
growth
help-wanted
mcp
model-problem
needs:compliance
nix
opentui
perf
pull-request
Mirrored from GitHub Pull Request
 tui
web
windows
zen
No Label
Milestone
No items
No Milestone
Projects
Clear projects
No project
Assignees
Clear assignees
yindo
No Assignees
1 Participants
Notifications
Due Date
No due date set.
Dependencies

No dependencies set.

Reference: anomalyco/opencode#1965
Delete Branch "%!s()"

Deleting a branch is permanent. Although the deleted branch may continue to exist for a short time before it actually gets removed, it CANNOT be undone in most cases. Continue?