Skip to content

feat(tool): add interactive terminal tool with persistent PTY sessions #23759

Closed as not planned

Description

@herjarsa

Problem

The current bash tool only supports one-shot command execution. The agent cannot interact with long-running processes, send follow-up input, or read incremental output from a running terminal session. This limits the agent's ability to work with REPLs, debuggers, servers, and other interactive CLI tools.

Proposed Solution

Add a new terminal tool with an action parameter that supports persistent PTY sessions:

  • run (default, backward-compatible): Same as current bash tool behavior
  • create: Start a persistent PTY session, returns sessionId
  • send: Write input to an existing session (commands, keystrokes, control sequences like Ctrl+C)
  • read: Read incremental output since last read using cursor-based replay
  • close: Terminate a session and clean up resources

Key design decisions:

  • Sessions stored via InstanceState<Map<PtyID, SessionState>> for per-directory isolation with auto-cleanup on disposal
  • FIFO eviction at max 20 sessions (oldest evicted first)
  • PowerShell exit code fix: uses $LASTEXITCODE instead of $? on Windows
  • Cursor-based output reading: no duplication, aligns with Pty.Service buffer model
  • Discriminated union Zod schema for type-safe parameter destructuring
  • Backward compatible: omitting action defaults to "run", producing identical behavior to the current bash tool

Activity

  1. added
    coreAnything pertaining to core functionality of the application (opencode server stuff)
    on Apr 21, 2026
  2. github-actions commented on Apr 21, 2026

    @github-actions
    Contributor

    This issue doesn't fully meet our contributing guidelines.

    What needs to be fixed:

    • This appears to be a feature request, but the title does not start with [FEATURE]: as required by the feature request template
    • The feature request template's pre-flight verification checkboxes are missing (confirming the feature hasn't been suggested before and that status:approved is needed before opening a PR)

    Please edit this issue to address the above within 2 hours, or it will be automatically closed.


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

    If you believe this was flagged incorrectly, please let a maintainer know.

  3. github-actions commented on Apr 22, 2026

    @github-actions
    Contributor

    This issue has been automatically closed because it was not updated to meet our contributing guidelines within the 2-hour window.

    Feel free to open a new issue that follows our issue templates.

  4. added a commit that references this issue on Apr 24, 2026
    d8a2087
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment

Metadata

Metadata

Assignees

Labels

coreAnything pertaining to core functionality of the application (opencode server stuff)

Type

No type

Projects

No projects

    Milestone

    No milestone

    Relationships

    None yet

    Development

    No branches or pull requests

    Issue actions