Hacktoberfest 2026: le issue che i maintainer hanno segnato per ottobre, aperte e adatte ai principianti. Sfoglia le issue Hacktoberfest

sidebar shows "in progress" on a fresh claude tab, and the protocol gives us no clean way to fix it

Aperta
  • Qualcosa non va?
#28 0 commenti 0 reazioni 0 assegnatari Vedi su GitHub

Nessuno ha ancora preso questa issue.

Valutazione

Difficoltà
5/5
Tempo stimato
Più di una settimana
Idoneità per principianti
35/100
Tipo di issue
Bug
Chiarezza
Da chiarire
Stato di attività
Tranquilla
Stack tecnologico
shell
Ambito
cli, developer-experience

Direzione di ricerca

Reproduce the three sidebar outcomes using the listed Warp, Claude Code, and plugin versions, then compare the session_start and stop payload shapes in the claude-code-warp, gemini-cli-warp, and opencode-warp adapters. Read should-use-structured.sh and the protocol findings linked in the issue. Done requires a maintainer decision on auto-detection, protocol changes, or public documentation rather than a self-contained adapter edit.

Scritto dal modello di indicizzazione a partire dal testo della issue.

Descrizione

summary

open a fresh warp tab, run claude, look at the sidebar — it immediately shows ⏳ In progress, even though the agent hasn't done anything yet. gemini cli and factory/droid tabs under identical conditions show their sidebar rows with no state pill at all. i can reproduce this on v2.0.0 stock with no fork, so this is upstream behavior, not a regression from pr #27.

the adapter has no clean way to fix it from the plugin side. writing this up so the warp team has the context.

reproduction

  1. open a fresh warp tab (stable build, v0.2026.04.15.08.45.stable_02)
  2. install warp@claude-code-warp v2.0.0
  3. run claude (claude code v2.1.116)
  4. sidebar row appears with ⏳ In progress pill before any prompt is submitted

for contrast: gemini and droid in the same terminal, with no warp plugin at all installed in their config dirs, render sidebar rows with no pill. just cli label + cwd + branch.

what actually happens (three observed states)

i tested three payload shapes to see if any combination produced the pill-free row:

what the plugin emits on session start sidebar renders as
nothing (zero warp://cli-agent events) >_ Terminal — pane isn't recognized as a claude session at all
session_start only ✦ Claude Code + ⏳ In progress pill
session_start + follow-up stop ✦ Claude Code + ✓ Done pill

all three are wrong in different ways. the pane-is-terminal outcome is the worst — it breaks agent-row identification. in progress is semantically incorrect (agent hasn't started a turn). done is semantically incorrect (agent hasn't done anything).

what i think is happening

gemini and factory/droid appear to be auto-detected by warp's own binary-name process watcher — no plugin is needed for them to appear as an agent row. for those two clis, warp ships the agent-row rendering independently of any osc protocol.

claude code has no equivalent path. the sidebar is fully osc-driven for agent:"claude" — the plugin has to emit at least one warp://cli-agent event for warp to flip from "generic terminal" to "agent row", and any osc seems to attach a default state pill.

what would help

any of these, roughly in order of cleanliness:

  1. auto-detect the claude binary, same way gemini and droid are detected. a plugin that hasn't emitted any osc would still get a clean sidebar row.
  2. document a protocol event that registers the row without attaching a state pill. session_start could be extended with an optional field like state: "idle" that warp respects, or a new session_ready event could exist for this.
  3. per-agent default state registration. let the plugin declare "this agent starts in the done/idle state, not running" once at install time.

option 1 is probably the simplest since the machinery exists for the other two clis.

tangential ask: writable sidebar description / icon (à la cmux)

the cli-agent protocol gives plugins three levers over what renders in the sidebar row: session_title, summary, tool_preview. cmux (github.com/zdriv/cmux) lets plugin authors update the sidebar description text and icon directly as the agent works — things like running pytest (23/41), waiting on github pr review, compiling rust workspace. it's the single most useful protocol capability for ui-driven workflows.

i've written a cmux plugin that uses this surface and it opens up a lot of richer statusing than what tool_preview allows. even a minimal status_description string field that any event can update would cover most of the same ground on warp's side.

the ergonomics problem underneath

there are no official docs for the cli-agent osc protocol. what i know comes from reading warpdotdev/claude-code-warp, warpdotdev/gemini-cli-warp, and warpdotdev/opencode-warp side by side. the protocol turns out to be small — six envelope fields, seven event names, one transport, one feature flag — but without a public spec the reverse engineering is guesswork:

  • no enumeration of which event names warp actually routes (had to grep event= literals across adapters)
  • no schema for optional vs required fields, no rejection/validation examples
  • no changelog — WARP_CLI_AGENT_PROTOCOL_VERSION=1 is the only versioning primitive, and the plugin's own should-use-structured.sh hardcodes a last-known-broken build by version string (v0.2026.03.25.08.24.stable_05)

i wrote up everything i inferred here: reverse-engineering warp's cli-agent notification protocol. a public spec — even a one-page readme in this repo — would make third-party adapters a lot less speculative. this issue is one of the symptoms.

context

  • claude code v2.1.116
  • warp v0.2026.04.15.08.45.stable_02
  • macos darwin 25.4.0 (apple silicon)
  • reproduced across multiple fresh tabs + fresh sessions

not asking for a specific fix — flagging the behavior + the protocol gap so the warp team can decide the right shape.

Lingua principale
Shell
Stelle
232
Fork
56
Merge medio
4g 15h
PR unite (30g)
1

Preparare l'ambiente

Questo progetto non fornisce container di sviluppo, Dockerfile né guida per i contributori, quindi l'ambiente è a tuo carico: parti dal suo README e consulta la nostra guida al primo contributo per i passaggi generali.

Come iniziare

  1. Leggi tutta la issue e poi la guida ai contributi del progetto.
  2. Commenta sulla issue per dire che te ne occupi tu — evita che due persone facciano lo stesso lavoro.
  3. Fai un fork del repository e lavora su un branch.
  4. Apri una pull request che faccia riferimento al numero della issue.

Altre issue di warpdotdev/claude-code-warp

Tutte le issue di warpdotdev/claude-code-warp

Issue simili

Altre issue su Shell/Bash

Ricevi le nuove issue nella tua casella

Un breve riepilogo di issue GitHub adatte ai principianti.