anomalyco / anomalyco/opencode

[FEATURE]: Terminal title (OSC 0/2) should distinguish waiting for user input (question/permission) vs active work

Open
#48,482 0 comments 0 reactions 1 assignee View on GitHub

@kommander is already working on this.

Since Sep 11, 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
Context & Gap

Existing proposals (#36294, #43904) discuss exposing working vs. idle status in the terminal window/tab title (OSC 0/2) via a spinner or glyph. Additionally, PR #45347 recently enhanced internal session tabs with status indicators (? for questions, ! for permissions).

However, the external OS terminal window/tab title (OSC 0/2) still has a critical blind spot: it does not distinguish between:

  1. The agent actively computing / executing tools in the background.
  2. The agent being blocked and waiting for user input (specifically: interactive question tool prompts or permission approval requests).
Proposed Enhancement

When updating the terminal title via OSC 0/2:

  • Waiting for user input (pending question tool prompt or permission request): display an attention prefix such as [?] OC | <title> (or [?] / [!]).
  • Actively working: display a rotating spinner (e.g. ⠋ OC | <title>) or busy indicator.
  • Idle: standard title OC | <title>.
Why this matters

When managing multiple concurrent sessions across terminal tabs or multiplexers (e.g. tmux, Kitty, WezTerm, GNOME Terminal, Windows Terminal):

  • Seeing the spinner tells the user: "Agent is still busy, let it run."
  • Seeing [?] immediately alerts the user: "Agent is paused waiting for my answer, switch to this tab."

Without this distinction, a user looking at tab titles either has to switch into every tab to check if a question is blocking progress, or mistake a blocked session for an active one and leave it unattended.

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.