opencode icon indicating copy to clipboard operation
opencode copied to clipboard

[FEATURE]: Configurable command timeout in config.json

Open JosXa opened this issue 2 months ago • 12 comments

  • [x] I have verified this feature I'm about to request hasn't been suggested before.

Describe the enhancement you want to request

The current 1-minute command timeout is too short for integration tests and other long-running operations. When running integration tests that may take longer than 1 minute, the timeout causes premature termination of commands.

Proposed Solution: Add a command_timeout setting to config.json that allows users to specify custom timeout duration.

Use Cases:

  • Integration tests that take longer than 1 minute
  • Build processes that require extended time
  • Database migrations or other long-running operations
  • CI/CD pipelines with extended execution times

Benefits:

  • Flexibility for different project requirements
  • Better support for long-running operations
  • Improved developer experience for integration testing
  • Maintains backward compatibility with existing setups

JosXa avatar Nov 05 '25 20:11 JosXa

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

  • #3583: Similar request for timeout configuration via CLI flag --timeout=60s
  • #1065: Discussion about controlling timeouts with config settings (closed with 30+ comments)
  • #655: Similar issue about tool invocation duration being too short for long-running operations

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

github-actions[bot] avatar Nov 05 '25 20:11 github-actions[bot]

@JosXa that's just the default timeout the agent can set it up to 10min currently. But yeah we could add an experimental setting for this I think tools + permissions are going to be tweaked in the config so I'd prefer making an experimental flag for now until we have a better hierachy

rekram1-node avatar Nov 05 '25 20:11 rekram1-node

You're right, I can tell it explicitly to use a specific timeout 👍 Something to know, or maybe document

JosXa avatar Nov 09 '25 14:11 JosXa

You're right, I can tell it explicitly to use a specific timeout 👍 Something to know, or maybe document

I'm having this problem at the /init stage, are you saying I can ask the model to raise the timeout BEFORE issuing the /init command ? It would indeed be useful to document how to change the timeout.

strk avatar Nov 14 '25 11:11 strk

@JosXa that's just the default timeout the agent can set it up to 10min currently.

How ?

strk avatar Nov 14 '25 11:11 strk

@strk Haven't tried, but intuitively I'd expect this to work:

"Whenever running terminal commands, use a timeout of 10 minutes. /init"

JosXa avatar Nov 14 '25 16:11 JosXa

@strk when the model calls bash commands there is an optional field for it to set a timeout, it can dynamically set that anytime it calls the tool.

rekram1-node avatar Nov 14 '25 16:11 rekram1-node

Hi, how to remove this timeout ?

The long running terminal commands are kicked after 60s

Please help

abda11ah avatar Nov 27 '25 18:11 abda11ah

ill add some config for it but for now @abda11ah just tell the llm to give it a higher timeout when it runs it

rekram1-node avatar Nov 27 '25 22:11 rekram1-node

@rekram1-node I noticed that the LLMs don't really get the idea that they can increase their command timeout parameter when it does time out. Could we add a note to the "this command expired" error that LLMs see along the lines of: "This command timed out. If you believe that it just needs more time to complete and did not stuck in an interactive shell, feel free to increase the timeout parameter" (or whatever it's named). This way, we could even reduce the default to like 15 or 30 seconds and let it retry with a higher timeout when needed. It dropping into an interactive command would then not be such a big impact to total duration of the task.

JosXa avatar Nov 28 '25 11:11 JosXa

Yeah we could/should update the error message if the llms aren't listening good idea

rekram1-node avatar Dec 01 '25 23:12 rekram1-node