Skip to content

[FEATURE]: Sub-agent abort recovery — show task_id and allow retry #24756

Closed as not planned

Description

@Ithril-Laydec

Feature hasn't been suggested before.

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

Describe the enhancement you want to request

Problem
When a sub-agent is aborted (connection drop, crash, Ctrl+C, or system shutdown), the TUI shows "Tool execution aborted" with no actionable information. The user has no way to:

  1. Identify which child session was running (no task_id / session ID visible)
  2. Resume the aborted sub-agent (no retry action available)
    The child session still exists in the database with its full message history, and the Task tool already supports resumption via task_id — but the UX provides no path to use it.
    This is especially painful for long-running sub-agents (complex implementations, multi-file refactors) where losing 5-10 minutes of work to a transient connection issue is a real problem.
    Current behavior
    ┃ General Task — Implement authentication module
    ┃ Tool execution aborted
    No session ID. No retry option. The user must start over or manually dig through session data.
    Proposed solution
  3. Display task_id on aborted Task tool parts (quick win, ~5 lines)
    The data is already available — metadata.sessionId is preserved by the abort handler in processor.ts (it spreads existing metadata and adds interrupted: true). The Task component in session/index.tsx just doesn't render it in the error state.
    ┃ General Task — Implement authentication module
    ┃ └ task_id: ses_0191a3b4c5d6AbCdEfGhIj
    ┃ Tool execution aborted
    This alone makes manual recovery possible (user can tell the parent agent to resume with that ID).
  4. "Retry" action on aborted Task tool parts (the real feature)
    A keybind (e.g., r when focused on an aborted tool part) that re-invokes the Task tool call with the same parameters plus task_id injected automatically. The child session continues where it left off and the result flows back to the parent naturally.
    This approach:

Activity

  1. added
    discussionUsed for feature requests, proposals, ideas, etc. Open discussion
    on Apr 28, 2026
  2. added
    coreAnything pertaining to core functionality of the application (opencode server stuff)
    webRelates to opencode on web / desktop
    on Apr 28, 2026
  3. github-actions commented on Apr 28, 2026

    @github-actions
    Contributor

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

  4. removed
    discussionUsed for feature requests, proposals, ideas, etc. Open discussion
    webRelates to opencode on web / desktop
    coreAnything pertaining to core functionality of the application (opencode server stuff)
    on May 3, 2026
  5. github-actions commented on Jul 4, 2026

    @github-actions
    Contributor

    To stay organized issues are automatically closed after 60 days of no activity. If the issue is still relevant please open a new one.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment

Metadata

Metadata

Assignees

Labels

No labels
No labels

Type

No type

Projects

No projects

    Milestone

    No milestone

    Relationships

    None yet

    Development

    No branches or pull requests

    Issue actions