[FEATURE] Semantic OSC markers in terminal output for third-party terminal integration

Resolved 💬 3 comments Opened Apr 7, 2026 by FurbySoup Closed Apr 11, 2026

Preflight Checklist

  • [x] I have searched existing requests and this feature hasn't been requested yet
  • [x] This is a single feature request (not multiple features)

Problem Statement

Claude Code's terminal output contains no structural metadata. Third-party terminals that host Claude Code cannot programmatically identify where conversation turns begin and end, which regions are code blocks, or which sections are tool call output. The only option is heuristic scanning of the rendered terminal buffer — which is fragile, breaks across Claude Code versions, and produces false positives that degrade user trust. This makes it impossible to build reliable block-level UX (copy buttons on code blocks, collapsible tool output, turn navigation) that users expect from a modern AI coding workflow.

Proposed Solution

Proposed solution:* Add OSC (Operating System Command) escape sequences to Claude Code's output that mark structural boundaries, following the same pattern VS Code established with OSC 633 for shell integration.

Motivation

Third-party terminals that host Claude Code (e.g., Quell) want to provide block-level interactions on AI responses — the same kind of structured output that claude.ai and the desktop app offer. However, Claude Code's Ink renderer outputs styled VT text with no structural markers. The terminal sees rendered text, not semantic structure.

Without markers, detection requires heuristic content scanning of the terminal buffer, which is:

  • Fragile — breaks when Ink's rendering changes between Claude Code versions
  • Ambiguous — code blocks, indented prose, and tool output are visually similar after rendering
  • Incomplete — conversation turn boundaries are invisible (BSU/ESU sync blocks fire 30x/sec during streaming, not once per turn)

VS Code solved this for shells with OSC 633 (prompt/command/output markers). The same pattern works for AI CLI tools.

Proposed Markers

Following the OSC 633 convention (already supported by VS Code, iTerm2, WezTerm):

| Sequence | Meaning | When Emitted |
|----------|---------|------------|
| ESC ] 634 ; A ST | Turn start (assistant response begins) | After user prompt is submitted, before first output token |
| ESC ] 634 ; B ST | Turn end (assistant response complete) | After final output token, before next prompt |
| ESC ] 634 ; C ; <lang> ST | Code block start | When opening ` fence is rendered |
| ESC ] 634 ; D ST | Code block end | When closing ` fence is rendered |
| ESC ] 634 ; T ; <tool> ST | Tool call start (with tool name) | When tool invocation begins rendering |
| ESC ] 634 ; U ST | Tool call end | When tool result finishes rendering |

634 is a private-use OSC code (no conflicts with standard sequences). ST is the String Terminator (ESC \ or \x9c).

Example Output

ESC]634;AST                          ← turn start
Here's the implementation:
ESC]634;C;pythonST                   ← code block start (Python)
def hello():
    print("Hello, world!")
ESC]634;DST                          ← code block end
ESC]634;T;EditST                     ← tool call start
Editing src/main.py...
ESC]634;UST                          ← tool call end
ESC]634;BST                          ← turn end

Impact

  • Zero cost for standard terminals — unknown OSC sequences are silently ignored by all compliant terminal emulators (xterm, Windows Terminal, iTerm2, etc.)
  • ConPTY compatible — OSC sequences pass through ConPTY unmodified (unlike some DCS sequences)
  • Enables ecosystem — any terminal hosting Claude Code can build structured UI without reverse-engineering Ink's rendering
  • Precedent exists — VS Code's OSC 633 for shell integration is widely adopted and proves the pattern

Who Benefits

  • Terminal emulator authors building Claude Code integrations
  • IDE terminal panels that want to provide code block actions
  • Accessibility tools that need to identify structural regions in AI output
  • Any tool that processes Claude Code's terminal output programmatically

Alternative Solutions

_No response_

Priority

Medium - Would be very helpful

Feature Category

Developer tools/SDK

Use Case Example

_No response_

Additional Context

  1. A user runs Claude Code inside Quell (a third-party Windows terminal built for AI CLI tools)
  2. Claude Code responds with a mix of prose explanation, a Python code block, and an "Edited src/main.py" tool call

result

  1. Quell's proxy intercepts the VT output stream and sees OSC 634 markers: turn start, code block start/end with

language tag, tool call start/end with tool name, turn end

  1. Quell places a "Copy" button at the top of the code block that copies clean Python (no ANSI codes, no terminal

wrapping artifacts) to the clipboard with one click

  1. The tool call output is collapsed by default to a single summary line "Edited src/main.py (+12 -3)" — the user can

expand it if they want to review the diff

  1. Ctrl+Up/Down jumps between conversation turns so the user can navigate a long session without scrolling through

hundreds of lines

  1. Without these markers, Quell must guess block boundaries from rendered terminal text. This breaks across Claude

Code versions, produces false positives (e.g., user-pasted markdown detected as a code block), and makes
collapse/expand impossible since there's no reliable way to know where a block ends

View original on GitHub ↗

This issue has 3 comments on GitHub. Read the full discussion on GitHub ↗