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

[yigitkonur]

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.