anomalyco/opencode
1
0
Fork 0
mirror of https://github.com/anomalyco/opencode.git synced 2026-07-23 10:45:33 -04:00
Code Issues 5.9k Packages Projects Releases 19 Wiki Activity

[FEATURE]: Show elapsed runtime per command / instruction in TUI + Replay #3706

New Issue
Open
opened 2026-02-16 17:41:11 -05:00 by yindo · 1 comment
yindo commented 2026-02-16 17:41:11 -05:00
Owner
Copy Link
Copy Source

Originally created by @luketych on GitHub (Dec 20, 2025).

Originally assigned to: @rekram1-node on GitHub.

Feature request: Surface elapsed runtime for active work (and make retries easier)

Context

During normal usage, OpenCode frequently executes commands or agent actions that may run for an extended or variable amount of time.

While these operations are in progress, the TUI provides limited feedback about their state. Users are left to infer whether the system is actively working, waiting on an external dependency, or no longer making progress.

This lack of visibility makes it difficult to decide whether to continue waiting, interrupt execution, or retry the operation. The goal of this request is to reduce that uncertainty without adding unnecessary complexity.

Problem

When a command, instruction, or agent action is executing, the TUI provides no indication of how long it has been running.

Without a sense of elapsed time, users have to rely on intuition and guesswork to decide whether to:

  • keep waiting,
  • interrupt execution, or
  • assume something has gone wrong.

This becomes more noticeable with:

  • long-running agent chains
  • tool or MCP calls
  • network-bound operations
  • shell commands that may block silently

Once execution is interrupted, restarting usually means reconstructing the same instruction manually.

Proposal

Two small affordances could significantly reduce this friction:

  1. Elapsed runtime visibility
    Show how long the currently active command or instruction has been running (e.g. in the status bar or alongside the active task).

    No progress estimation is needed — just elapsed time.

  2. A simple way to retry the last instruction
    After a task completes or is interrupted, provide a way to re-run the most recent instruction without retyping or rebuilding context.

    This could be exposed as a button, keybinding, or command — the exact form is flexible.

Why this helps

Elapsed time is a subtle but powerful signal. It lets users decide for themselves whether something feels normal or off, and whether waiting longer makes sense.

Combined with an easy retry path, interruption becomes less costly and less stressful. Users can stop work earlier when something feels wrong, knowing they can resume without friction.

Together, these changes:

  • reduce hesitation during long-running tasks
  • make interruptions feel reversible instead of destructive
  • increase trust by making execution more observable

Notes

This request is intentionally scoped to visibility and ergonomics, not policy or automation. More advanced behavior (warnings, thresholds, hooks, etc.) may naturally suggest itself later once time becomes a visible signal.

Closing

This isn’t a large feature, but it addresses a common moment of uncertainty during real usage.

Curious whether others have felt the same hesitation while waiting — and whether making time visible would change how they interact with long-running work.

Originally created by @luketych on GitHub (Dec 20, 2025). Originally assigned to: @rekram1-node on GitHub. ## Feature request: Surface elapsed runtime for active work (and make retries easier) ### Context During normal usage, OpenCode frequently executes commands or agent actions that may run for an extended or variable amount of time. While these operations are in progress, the TUI provides limited feedback about their state. Users are left to infer whether the system is actively working, waiting on an external dependency, or no longer making progress. This lack of visibility makes it difficult to decide whether to continue waiting, interrupt execution, or retry the operation. The goal of this request is to reduce that uncertainty without adding unnecessary complexity. --- ### Problem When a command, instruction, or agent action is executing, the TUI provides no indication of **how long it has been running**. Without a sense of elapsed time, users have to rely on intuition and guesswork to decide whether to: - keep waiting, - interrupt execution, or - assume something has gone wrong. This becomes more noticeable with: - long-running agent chains - tool or MCP calls - network-bound operations - shell commands that may block silently Once execution is interrupted, restarting usually means reconstructing the same instruction manually. --- ### Proposal Two small affordances could significantly reduce this friction: 1. **Elapsed runtime visibility** Show how long the currently active command or instruction has been running (e.g. in the status bar or alongside the active task). No progress estimation is needed — just elapsed time. 2. **A simple way to retry the last instruction** After a task completes or is interrupted, provide a way to re-run the most recent instruction without retyping or rebuilding context. This could be exposed as a button, keybinding, or command — the exact form is flexible. --- ### Why this helps Elapsed time is a subtle but powerful signal. It lets users decide for themselves whether something feels normal or off, and whether waiting longer makes sense. Combined with an easy retry path, interruption becomes less costly and less stressful. Users can stop work earlier when something feels wrong, knowing they can resume without friction. Together, these changes: - reduce hesitation during long-running tasks - make interruptions feel reversible instead of destructive - increase trust by making execution more observable --- ### Notes This request is intentionally scoped to visibility and ergonomics, not policy or automation. More advanced behavior (warnings, thresholds, hooks, etc.) may naturally suggest itself later once time becomes a visible signal. --- ### Closing This isn’t a large feature, but it addresses a common moment of uncertainty during real usage. Curious whether others have felt the same hesitation while waiting — and whether making time visible would change how they interact with long-running work.
yindo added the opentuidiscussion labels 2026-02-16 17:41:11 -05:00
yindo commented 2026-02-16 17:41:11 -05:00
Author
Owner
Copy Link
Copy Source

@github-actions[bot] commented on GitHub (Dec 20, 2025):

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

  • #5333: [FEATURE]: Graceful handling of queued messages after session interrupt - Related feature about task management, interrupts, and UI feedback during execution

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

@github-actions[bot] commented on GitHub (Dec 20, 2025): This issue might be a duplicate of existing issues. Please check: - #5333: [FEATURE]: Graceful handling of queued messages after session interrupt - Related feature about task management, interrupts, and UI feedback during execution Feel free to ignore if none of these address your specific case.
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 discussion opentui
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#3706
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?