Enhancement Category
Code mode improvements
Problem or Use Case
When the tool is in code mode, the execute_go_code tool is used to execute Go code generated by the LLM. This tool accepts an optional executionTimeout parameter (defaulting to 300s, but often set lower by the model or user intent).
Currently, internal/agent/response_printer.go explicitly formats the output for execute_go_code to show the Go code in a syntax-highlighted block. However, it ignores the executionTimeout parameter.
This means the user has no visibility into what timeout the LLM has requested for the execution. If a script is time-sensitive or long-running, not knowing the timeout can make debugging difficult (e.g., distinguishing between a hang and a pending timeout, or understanding why it was killed).
Proposed Solution
Modify internal/agent/response_printer.go in the renderToolCall method.
When handling codemode.ExecuteGoCodeToolName, it should:
- Check if
executionTimeout is present in toolCall.Parameters.
- If present, display it in the output header or alongside the code block.
Example Output:
#### [tool call] (timeout: 60s)
```go
package main
// ...
```
Implementation Details:
- Parse
executionTimeout from the parameters map (it should be a float64 or int).
- Format the string passed to
g.contentRenderer.Render.
Alternatives Considered
We could print the full JSON for execute_go_code like other tools, but that would hurt readability for the code itself. The current special handling is good, it just needs to be more comprehensive.
Impact Scope
Users of specific AI providers
Enhancement Category
Code mode improvements
Problem or Use Case
When the tool is in code mode, the
execute_go_codetool is used to execute Go code generated by the LLM. This tool accepts an optionalexecutionTimeoutparameter (defaulting to 300s, but often set lower by the model or user intent).Currently,
internal/agent/response_printer.goexplicitly formats the output forexecute_go_codeto show the Go code in a syntax-highlighted block. However, it ignores theexecutionTimeoutparameter.This means the user has no visibility into what timeout the LLM has requested for the execution. If a script is time-sensitive or long-running, not knowing the timeout can make debugging difficult (e.g., distinguishing between a hang and a pending timeout, or understanding why it was killed).
Proposed Solution
Modify
internal/agent/response_printer.goin therenderToolCallmethod.When handling
codemode.ExecuteGoCodeToolName, it should:executionTimeoutis present intoolCall.Parameters.Example Output:
Implementation Details:
executionTimeoutfrom the parameters map (it should be a float64 or int).g.contentRenderer.Render.Alternatives Considered
We could print the full JSON for
execute_go_codelike other tools, but that would hurt readability for the code itself. The current special handling is good, it just needs to be more comprehensive.Impact Scope
Users of specific AI providers