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

[FEATURE]: Configurable command timeout in config.json #2616

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

Originally created by @JosXa on GitHub (Nov 5, 2025).

Originally assigned to: @rekram1-node on GitHub.

  • 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
Originally created by @JosXa on GitHub (Nov 5, 2025). Originally assigned to: @rekram1-node on GitHub. - [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
yindo commented 2026-02-16 17:36:29 -05:00
Author
Owner
Copy Link
Copy Source

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

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] commented on GitHub (Nov 5, 2025): 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.
yindo commented 2026-02-16 17:36:29 -05:00
Author
Owner
Copy Link
Copy Source

@rekram1-node commented on GitHub (Nov 5, 2025):

@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 commented on GitHub (Nov 5, 2025): @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
yindo commented 2026-02-16 17:36:29 -05:00
Author
Owner
Copy Link
Copy Source

@JosXa commented on GitHub (Nov 9, 2025):

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

@JosXa commented on GitHub (Nov 9, 2025): You're right, I can tell it explicitly to use a specific timeout 👍 Something to know, or maybe document
yindo commented 2026-02-16 17:36:29 -05:00
Author
Owner
Copy Link
Copy Source

@strk commented on GitHub (Nov 14, 2025):

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 commented on GitHub (Nov 14, 2025): > 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.
yindo commented 2026-02-16 17:36:29 -05:00
Author
Owner
Copy Link
Copy Source

@strk commented on GitHub (Nov 14, 2025):

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

How ?

@strk commented on GitHub (Nov 14, 2025): > [@JosXa](https://github.com/JosXa) that's just the default timeout the agent can set it up to 10min currently. How ?
yindo commented 2026-02-16 17:36:29 -05:00
Author
Owner
Copy Link
Copy Source

@JosXa commented on GitHub (Nov 14, 2025):

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

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

@JosXa commented on GitHub (Nov 14, 2025): @strk Haven't tried, but intuitively I'd expect this to work: "Whenever running terminal commands, use a timeout of 10 minutes. /init"
yindo commented 2026-02-16 17:36:29 -05:00
Author
Owner
Copy Link
Copy Source

@rekram1-node commented on GitHub (Nov 14, 2025):

@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 commented on GitHub (Nov 14, 2025): @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.
yindo commented 2026-02-16 17:36:29 -05:00
Author
Owner
Copy Link
Copy Source

@abda11ah commented on GitHub (Nov 27, 2025):

Hi, how to remove this timeout ?

The long running terminal commands are kicked after 60s

Please help

@abda11ah commented on GitHub (Nov 27, 2025): Hi, how to remove this timeout ? The long running terminal commands are kicked after 60s Please help
yindo commented 2026-02-16 17:36:29 -05:00
Author
Owner
Copy Link
Copy Source

@rekram1-node commented on GitHub (Nov 27, 2025):

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 commented on GitHub (Nov 27, 2025): ill add some config for it but for now @abda11ah just tell the llm to give it a higher timeout when it runs it
yindo commented 2026-02-16 17:36:29 -05:00
Author
Owner
Copy Link
Copy Source

@JosXa commented on GitHub (Nov 28, 2025):

@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 commented on GitHub (Nov 28, 2025): @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.
yindo commented 2026-02-16 17:36:29 -05:00
Author
Owner
Copy Link
Copy Source

@rekram1-node commented on GitHub (Dec 1, 2025):

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

@rekram1-node commented on GitHub (Dec 1, 2025): Yeah we could/should update the error message if the llms aren't listening good idea
yindo commented 2026-02-16 17:36:29 -05:00
Author
Owner
Copy Link
Copy Source

@rekram1-node commented on GitHub (Dec 9, 2025):

we will have something more appropriate in the config later, for now we will have:
OPENCODE_EXPERIMENTAL_BASH_DEFAULT_TIMEOUT (supported in next release also this is in milliseconds)

@rekram1-node commented on GitHub (Dec 9, 2025): we will have something more appropriate in the config later, for now we will have: OPENCODE_EXPERIMENTAL_BASH_DEFAULT_TIMEOUT (supported in next release also this is in milliseconds)
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#2616
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?