Feature request: render the custom statusLine in the VS Code extension panel (parity with spinnerVerbs)

Not EXACTLY what your asking but https://norrin.dev/ is a very cool extension for Claude Code that gives you the ability to see inline diff, accept/ reject per hunk, and track files.

Still present in 2.1.239 (this issue was filed against 2.1.210), and I can add bundle-level detail on why it fails silently.

Grepping the installed extension:

• webview/index.js — the bundle that renders the native panel — has zero matches for statusLine, status_line, or status-line.
• extension.js has 5 matches, and every one of them is settings-schema definition (statusLine:Z({type:ye("command"),command:k(),padding:...,refreshInterval:...}), the subagentStatusLine schema, the key list of command-valued settings, and the disableAllHooks description text). Nothing that executes the command or forwards a result to the panel.

So the config is parsed and validated, and then has no consumer on the panel side. That's why it fails with no warning and no error — a perfectly valid statusLine block is simply inert. Working out that the problem was neither my script nor my settings took a while, and the schema validation actively misleads here, since an invalid block would be rejected while a valid one silently does nothing.

Worth folding into the same parity ask: footerLinksRegexes also has zero matches in webview/index.js. The footerLink matches that are there belong entirely to the onboarding tooltip's "Docs · Issues · Hide onboarding" row. The webview does define its own badge classes, but they're unrelated surfaces — MCP server connection status, a count on the Plugins/Marketplaces tabs, and the "official marketplace" icon on a plugin card. So both documented routes for getting custom text into the footer area are terminal-only, not just statusLine.

A line in the settings docs noting that statusLine is terminal-only would be a cheap mitigation in the meantime.

On workarounds: there isn't one inside the GUI. The best available is to run the same script from a Stop / SessionStart hook, have it write a plain file, and keep that file open in a pinned split tab so the editor live-reloads it. That works, but it is a poor substitute for what this issue asks for, and it should not be read as reducing the need for the feature:

• it lives outside the Claude Code UI entirely — a separate editor tab, not a row in the panel;
• it costs a permanently occupied editor split, which is exactly the screen real estate the status line was going to avoid using;
• it's an externally maintained file that only refreshes when a hook happens to fire, rather than a live surface the extension owns;
• and it can't reproduce the per-session framing a status line gets for free, because nothing on disk maps an IDE window to the session its panel has open (the ~/.claude/ide/*.lock files carry pid, workspace folders and an auth token — no session id — and one pid spans several workspaces).

As far as I can tell the extension itself offers no in-GUI mitigation at all: no setting, no command, no alternate surface. It's the feature or nothing.

Possibly related demand: #50744 asked for conversation timestamps in the VS Code panel; it's closed as not planned and carries a stale label rather than any maintainer decision on the merits.

Environment: Windows 11, native panel (claudeCode.useTerminal unset, i.e. its default of false; claudeCode.preferredLocation: "panel"). My observation is in a VS Code fork (Antigravity IDE) running the published anthropic.claude-code extension build 2.1.239 — I haven't re-checked the bundle under stock VS Code, so I can't personally confirm it there, though I'd expect the same since it's the same published artifact.

One note for anyone copying the hook workaround: make sure the script writes nothing to stdout. SessionStart hook stdout is added to the session context, so a stray console.log would quietly consume tokens on every session start.

Some evidence on where this stops, from extension 2.1.245 (CLI 2.1.246, VS Code 1.134.0, Windows 11):

statusLine appears three times in extension.js, all of them configuration validation — the settings schema, the helper-command list, and the disableAllHooks description. It appears zero times in webview/index.js, which renders the UI.

So the setting is parsed and validated, then dropped: a status line script that produces output in the terminal produces nothing in the extension panel, with no warning that it will be ignored. From the user's side it reads as a silent no-op rather than an unimplemented feature, which is what makes it costly to diagnose.

Worth noting the practical consequence, since the status line is the usual way to surface the active model: with it unrendered here, and the SessionStart hook payload carrying no model field in this version, there is no way for a user to surface the current model in the extension at all. I've written that up in more detail in #74349.