Desktop app draws a mod's AbovePrompt band in only one chat at a time

Same issue on macOS, with one more symptom: in some chats the band is never drawn, even when that chat is the active panel.

Environment: Claude desktop app 2.19675.0 on macOS 27.0.1, Code tab, several chats open. Claude Code 2.1.286. The mod is an installed plugin that draws both a SessionMode footer item and an AbovePrompt band.

What we see:

• In 4 chats that were already open when the app started, AbovePrompt is never requested.
• The mod records every band render per session. These chats have no record at all, while their SessionMode item renders and updates normally.
• It stays that way when the chat is the focused, active panel, and after all of the following:
• /reload-plugins
• a full app quit and reopen
• Cmd+R (window reload)
• closing and reopening the chat
• clearing the mod's stored state for that chat
• A brand-new chat, and one older chat that was not open in a panel when the app started, both draw the band as expected.

Where it seems to happen: in the renderer bundle, the band is gated on three conditions:

Band:_(function(e){…{sessionRef:n,isPanelActive:r}=e,i=Xe(n),a=n?.type==="local"&&i&&r?n:null…

• Xe reads the session's meta query and returns meta?.isShared === false, falling back to false when there is no data.
• The local fetchMeta builds that meta with isShared hard-coded to false.
• The meta query is called with refetchOnMount off for local sessions. Focus and interval refetch apply only to remote and bridge sessions.

Our reading is that in the affected chats the meta query came back empty once and is never fetched again, so i stays false. We could not observe that first empty fetch directly, so this part is inferred from the code.

Ask:

• Treat a missing meta for a local session as not shared, or refetch it.
• Draw each chat's own band, as already asked above.

Related: #99211. The rebuild on every ui_invalidate is what made our band's buttons lose clicks until we removed every per-second state write.

+1

Same on Windows with Claude desktop 2.19675.1 and Claude Code 2.1.288/2.1.289, five chats in split view. The band follows the leftmost pane, not keyboard focus: with the focused chat in pane 4, only pane 1 drew it. Moving a chat into the leftmost pane gave it the band, and moving one out took it away (two chats, both directions). The mod was live in every chat: its 60 s session.start timer ran in every session's process.

Same here on Windows, with a measurement that points at the split view's left pane rather than the focused pane.

Environment: Claude desktop app 2.19675.1.0 (Windows, MSIX), Code tab, main window split into two panes side by side. Claude Code 2.1.286. The mod is loaded in every chat via CLAUDE_CODE_PLUGIN_DIRS and draws an AbovePrompt band. A temporary counter in the mod recorded every ui.render call for AbovePrompt per session.

What we measured:

• A chat in the right pane: the mod was loaded (session.start ran, its slash command answered, its data was ready), but AbovePrompt was requested 0 times over about 20 minutes. That stayed 0 after typing /reload-plugins and the mod's command directly into that pane.
• The same chat, moved into the left pane: AbovePrompt requests started within seconds (surface=desktop, hasSurvey=false) and the band showed. The chat that took the right pane lost its band.
• Back in the right pane: the requests stopped again.
• A terminal session running the same mod at the same time got the band normally.

So in our case the gate behaves like "left (first) pane only": typing into the right pane did not make it ask for the band, while moving it to the left did.

Still happening on the latest builds: Claude desktop 2.26454.2 on macOS 27.0.1, Claude Code 2.1.293.

Two chats side by side in split view, same plugin loaded in both. The left pane's band draws and updates every second; the right pane never gets one. I added a temporary command to the plugin that reports what its last AbovePrompt render did: in the left chat it said the band was drawn, in the right chat AbovePrompt had never been called at all, even after that chat finished a turn.

Opening the same chat in its own window brings the band straight back.

So it's tied to the pane, not the session or the plugin. Each pane should get its own band, the same as it does when the chat has a window to itself.

Adding a detail on Claude desktop 2.26454.2 (macOS), Claude Code 2.1.295: it is not only the AbovePrompt band. A plugin Pane opened with $.ui.open (here by a /pages command the plugin registers) also collapses as soon as its chat is moved out of the leftmost split-view pane, and comes back when the chat is dragged back to the leftmost pane. The plugin's status line ($.ui.status) behaves the same way. So every plugin surface follows the leftmost pane, not the chat it belongs to.

Same here on Windows 11: Claude desktop 2.26454.2, Claude Code 2.1.293. The session in the right split pane never gets a ui.render call for AbovePrompt. A diagnostic counter stayed at 0 for about 8 minutes, even though the mod calls $.ui.invalidate('ui.render') every 30 s and $.session.surfaces() returns ['desktop']. A few points that might help:

• Opening that same session in a pop-out window draws the band immediately, and the render count rises. The split pane stays empty.
• A full app restart (mod loaded when the session resumed, before any view attached) and re-opening the session in a fresh split pane don't change the result.
• $.ui.open({ id }) from a command in the right pane returns { isPlaced: true }, but no pane appears.

Linux data point, and one result that differs from the status line comment above.

Environment: Claude desktop app 2.26454.2 on Linux (Wayland), Code tab, Claude Code 2.1.293. Two sessions side by side. The mod is loaded in every session via CLAUDE_CODE_PLUGIN_DIRS.

Band: same as the reports above. AbovePrompt draws in the left pane only. Moving the same session into the left pane makes the band appear, and focus does not matter. The mod has no pane or session logic.

Status line: $.ui.status is drawn in the right pane here. A new session in the right pane shows the mod's line in its composer footer and no band above the prompt. The line reads ctx 15% · 5h 65% · wk 90%. An earlier comment says the status line follows the leftmost pane too. On this build it does not.

<img width="2000" height="225" alt="Image" src="https://github.com/user-attachments/assets/04a6d05f-afa5-4bb0-b8d8-e36206a64bb2" />

Screenshot, cropped to the composers: the left pane draws the band, the right pane draws no band and shows the status line in its footer. The left session started before I added the status line to the mod, so its footer has none.

I use the status line as a workaround for a per-pane usage readout. It also needs CLAUDE_CODE_PLUGIN_DIR_WATCH=1 in the settings env block to reload on save in desktop sessions.

Still happening on Claude desktop 2.31226.1.0 (Windows 11, MSIX), Claude Code 2.1.295 — newer than every build reported above. Three mods from one marketplace (two AbovePrompt bands plus a third band and a Pane), two chats in split view. The right-pane chat had all mods live (one of them writes a per-turn cost record for that session, and it kept growing), yet none of its bands was drawn, also while it was the focused pane. Swapping the panes moved all bands with the session; the same session opened in a pop-out window drew all of them at once. So the gate is still the leftmost pane, not focus or the session.