[FEATURE]: Session-scoped terminals + optional terminal context for the model #43758

Activity

1. github-actions

   assigned

   Hona

   on Aug 21, 2026
2. iyernaveenr commented on Aug 29, 2026

   

   iyernaveenr

   on Aug 29, 2026

   Author

   More actions

   Any thoughts on the direction here? Happy to open the first small PR (the session-ownership part) if that is easier to review than discussing in the abstract.
3. ryanwyler commented on Aug 30, 2026

   

   ryanwyler

   on Aug 30, 2026

   Contributor

   More actions

   I wrote runner-mcp that I use with the TUI version of opencode, claude and codex that solves this problem for me. I'm not sure if this is similar to what you're talking about.

   https://github.com/gignit/runner-mcp
4. iyernaveenr commented on Aug 30, 2026

   

   iyernaveenr

   on Aug 30, 2026

   Author

   More actions

   I wrote runner-mcp that I use with the TUI version of opencode, claude and codex that solves this problem for me. I'm not sure if this is similar to what you're talking about.

   https://github.com/gignit/runner-mcp

   No - an MCP server cannot provide this. The proposal changes the GUI app itself: the terminal pane each chat tab already renders becomes part of that chat session. Each tab owns its PTYs (today they are shared across all tabs in a workspace), commands the user types there become opt-in context for the model, and in the opt-in reverse mode the model's commands run in that same visible interactive shell (shared cwd/env/history) instead of a hidden subprocess. The pane-to-session binding and the per-session context injection are app-internal state, which is why this needs changes in the app's session/server/PTY code rather than external tooling. No installs; both options default off.
5. iyernaveenr

   added 3 commits that reference this issue on Sep 3, 2026

   feat(core): session-owned PTYs with command capture

   ...

   f179dd5

   feat(opencode): enforce PTY session ownership and expose terminal con…

   ...

   3b5433d

   feat(app): session-scoped terminal stores

   ...

   55b71ae
6. iyernaveenr commented on Sep 7, 2026

   

   iyernaveenr

   on Sep 7, 2026

   Last edited by iyernaveenr

   Author

   More actions

   Following the CONTRIBUTING guidance to base on v2, the first part (session ownership of PTYs) is now implemented against upstream/v2: https://github.com/iyernaveenr/opencode/tree/naveen_r_iyer/v2-session-terminals

   Single commit, 19 files. Optional sessionID on PTY create; session-aware endpoints accept a sessionID claim and answer 404 for PTYs owned by another session (no existence leak); the GUI keys its terminal store per chat tab so each conversation keeps its own shells across tab switches. Callers that send no sessionID see today's behavior unchanged. Tests cover core, HTTP ownership end to end, and the app store keys.

   Not opening a PR until the direction is confirmed, per the design-review guardrail. Happy to adjust the approach.

   One question on direction, having read the persistent-pty work (#44832, #44971): the daemon is already keyed by session for the TUI, while the desktop app still uses the workspace-scoped /api/pty. If the plan is to migrate the app to persistent-pty, I would rather build the session-terminal work on that (its terminal/read endpoint is a natural source for the terminal-context part) than extend the legacy surface as the linked branch does. Either way works for me.
7. iyernaveenr

   added 3 commits that reference this issue on Sep 26, 2026

   feat(core): session-owned PTYs with command capture

   ...

   a67d8ae

   feat(opencode): enforce PTY session ownership and expose terminal con…

   ...

   2f5daf5

   feat(app): session-scoped terminal stores

   ...

   2c1b1ea
8. opencodejr commented on Oct 28, 2026

   

   opencodejrBot

   on Oct 28, 2026

   Contributor

   More actions

   Thanks for the detailed proposal, @iyernaveenr! To restate it: you'd like each chat session to own its terminals instead of sharing them across the workspace. Commands run there would be captured with OSC 133 shell-integration markers, and the model could optionally see them (terminal_context: off / tool-only / ambient / ambient-full). In the other direction, the model's shell commands could optionally run visibly in that session's terminal (shell_in_terminal: off / visible). Both would be off by default, so nothing changes unless you opt in.

   Maintainers will look at the direction and let you know whether it fits before you open PRs. Related issues:

   • [FEATURE]:Interactive Shell Passthrough / Shared Pseudoterminal (pty) for MFA/auth/Cowork #53781: asks for a shared PTY so you can step into the agent's shell commands, for example for passwords or MFA prompts. This overlaps with your shell_in_terminal: visible idea.
   • PTY has no flow control: yes command pegs the server, grows memory without bound, and starves input #53473: PTY flow control and unbounded memory use, which may matter for the capture buffer.

   Most of this can't be done as a plugin today. Plugins can only read persistent terminals; they can't own PTYs per session or send the shell tool's commands to a terminal.
9. mleivaDesarrollos commented on Nov 1, 2026

   

   mleivaDesarrollos

   on Nov 1, 2026

   More actions

   Strong +1, and a proposal to frame the same idea one level up: the missing thing is not a command — it is a channel between a pane and a conversation.

   Today the TUI has two buffers that both hold shell output and no way to move text between them:

   • the pane — a persistent PTY, visible to the human, opaque to the model;
   • the conversation — visible to the model, and until it is pasted in, unaware the pane exists.

   Everything users do about that (select-and-paste, retyping the command into chat, writing a client, this thread) is a workaround for the absent primitive. Two data points from the plumbing today, because it is closer to a channel than it looks:

   1. A pane's retained buffer is already readable: GET /api/experimental/persistent-pty/{ptyID}/snapshot returns .data.text — the whole buffer, not the visible rows (a 120-line seq in a 12-row pane came back as 120 lines), without attaching or taking control. GET /api/experimental/session/{sessionID}/terminal lists the session's panes.
   2. That buffer is the only one in the product that cannot be paged. PersistentPty.Info tracks absolute byte cursors (output.head / output.tail), yet no endpoint reads by them, while the agent's own shell output already does exactly that: GET /api/shell/{id}/output?cursor=&limit= → {output, cursor, size, truncated}, "page through captured combined output by absolute byte cursor". The chat side has messages.copy / session.copy. The pane has no equivalent — not for the agent, not for the human.

   So the request, in the shape I would build it:

   a. terminal.read with a cursor, not just a tail. {after?: cursor, limit?} → {text, cursor, size, truncated}, ANSI stripped by default with an explicit raw mode. Cursor paging is what makes a pane followable: read the delta of a running build or tail -f without re-reading the whole buffer, and without flooding context. This is the one piece that makes the channel worth having rather than a novelty.

   b. terminal.search <regex>. For long output the useful question is rarely "give me 500 lines", it is "which line failed". A bounded, server-side match with a little context returns a dozen lines instead of a megabyte, and it is the difference between a mechanism that fits in a context window and one that does not.

   c. terminal.last_command — your part 2 (OSC 133). Command boundaries are the unit people actually mean: exit status plus that command's output range. It subsumes most of (b) in practice, and it is the only version that answers "why did that fail?" without heuristics.

   d. The human end of the same channel. There is no terminal.copy binding at all — the pane exposes select / toggle / close / suspend / title, while messages.copy and session.copy exist for chat. Copy or export of a pane buffer should be a command, and it would also be the natural place to send a pane's output into the conversation deliberately, rather than by paste.

   Guardrails I would expect, and would want as a user: pull-only by default (nothing streams into context unprompted), hard caps with explicit truncation reporting, the same permission action that governs shell so a repo or org can deny it, and no input injection — writing into a pane must never race the user or answer a password prompt (that is #53781's problem, and one I have hit in exactly that form).

   On the workaround, to be explicit: I am not proposing that a script ships. I wrote one — a ~60-line client over those two GETs, session id from $OPENCODE_SESSION_ID — only because (a)–(d) do not exist, and I would drop it the day one of them does. Two things it cannot fix and a first-class version can:

   • Retained history is 10,000 bytes (OpenTUI maxScrollback default, never passed by the TUI). In the session I measured, 27,669 bytes had streamed and 5,626 were still readable. Filed against OpenTUI as core: maxScrollback is constructor-only and unreachable from Solid/React elements, so hosts cannot configure embedded terminal history opentui#1910, since the option is constructor-only and unreachable from a framework element.
   • GET .../terminal/read?lines=N returns null unless the PTY is the current one attached to a view — easy to misread as "no output". snapshot has no such condition; worth documenting or fixing either way.

   Also relevant: #61053 — the pane's viewport is frozen during a selection drag and the wheel is dropped in the mouse parser, so a human cannot select across screens. Same buffer, same gap, other direction.

   Happy to prototype (a) or (b) against the existing endpoints and report back, and to test parts 2/4 of your proposal on a real setup (TUI over SSH) if that is useful.

   👍React with 👍1Reacted by Michalis Papadopoullos
10. mleivaDesarrollos commented on Nov 2, 2026

    

    mleivaDesarrollos

    on Nov 2, 2026

    More actions

    Scoping note for part 4 of the proposal, found while checking upstream: the "send pane output to the conversation deliberately" half already shipped for the desktop app — #58420, merged 2026-10-23, "quote selected terminal output into the composer": selecting output in the integrated terminal shows a Quote toolbar that adds a quote chip to the composer.

    So the concept is not missing, the TUI equivalent is (the keybind reference has session.copy and messages.copy but nothing for the pane). Worth folding in as "same affordance in the TUI" rather than designing a second mechanism — which leaves the cursor-paged read from my earlier comment as the one genuinely new piece on the TUI side.