anomalyco / anomalyco/opencode

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

Open
#43,758 4 comments 0 reactions 1 assignee View on GitHub

@Hona is already working on this.

Since Aug 21, 2026.

Dominant language
TypeScript
Stars
209k
Forks
27.5k
PR merge metrics
PR metrics pending

Description

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: The GUI shows a terminal beside each chat, but terminals are workspace-scoped (since #12468) -- all tabs in a directory share them -- and nothing typed there is visible to the model. To ask "why did that fail?" you have to paste output or rerun the command through the shell tool. The disconnect goes both ways: the model's own shell commands run in hidden subprocesses, so you can't watch them execute or reuse the resulting shell state.

Proposal:

  1. Key PTYs to the owning chat session (sessionID on the PTY schema + connect-ticket scope, session-keyed terminal stores in the app). Each tab keeps its own shells across switches; unowned PTYs keep today's behavior.
  2. Capture commands via shell integration markers (OSC 133, same mechanism as VS Code) into a bounded, in-memory, per-session ring.
  3. Expose via a terminal_context config: off (default -- exactly today's behavior, no capture) / tool-only / ambient / ambient-full.
  4. Use the same plumbing in the reverse direction: a shell_in_terminal config: off (default -- today's isolated subprocess) / visible -- the model's shell commands are typed into the session's own terminal and output is read back through the same capture, with subprocess fallback when the terminal is absent or busy.

I have a working implementation of all four parts with tests, split-able into small PRs if the direction is acceptable. Happy to adjust the design.

Contributor guide

Open the contributing guide

First steps

  1. Read the whole issue, then the project's contributing guide.
  2. Comment on the issue to say you are picking it up — it saves two people doing the same work.
  3. Fork the repository and make your change on a branch.
  4. Open a pull request that references the issue number.

Assessment

This issue has not been assessed yet.

Get new issues in your inbox

A short digest of beginner-friendly GitHub issues.