A fileOpener cannot open another file or retitle its tab, so navigating inside one leaves a stale tab title

[andrewkchan]

Human comments

This would be useful so that plugins that provide a fileOpener view can also show a filetree that opens other files and rename the file tab whenever a new file is opened.

E.g. my monaco plugin below cannot rename its tab:

Screen.Recording.2026-08-20.at.4.24.31.PM.mov

---

The workflow

I wrote a fileOpener plugin (a Monaco editor) with a file tree in it, so you can browse the project and jump between files without leaving the tab. Clicking a file in that tree should do what clicking a file anywhere else in BB does: show it, in a tab labelled with its name.

What happens today

A fileOpener component receives { path, source } and nothing else. There is no way to ask BB to open a different file, and no way to retitle the tab it is rendering in. So the only thing a plugin can do is swap the file in place — after which BB's tab keeps naming the file the tab was opened with, and the two disagree until the tab is closed. Reopening the tab returns to the original file, because the path is what BB persisted in the tab's params.

The gap is specific to this slot. Two sibling slots already have the missing halves:

• messageDirective components get openWorkspaceFile(path) — "open this worktree-relative path in the host's workspace viewer".
• threadPanelAction gets openPanel({ title, params }), which sets a tab title and, per its own docs, focuses an existing tab "(updating its title)" when params match.

So BB can already do both things a fileOpener needs; they are just not offered to it.

What you would expect

Either half would resolve it, and they compose well:

1. openWorkspaceFile-style capability on fileOpener props, matching messageDirective. Clicking a file in a plugin's own UI would then route through BB's normal open path — correct title, correct tab identity, correct persistence — and a plugin never has to simulate navigation. This is the one I would pick: it is an existing capability handed to one more slot, and it keeps BB as the owner of what a tab means.
2. A way for a component to retitle its own tab, e.g. a setTitle(title) prop, for plugins that deliberately manage their own content and only need the label to keep up.

Context and alternatives

The workaround is to register a threadPanelAction that renders the same editor and call useBbNavigate().openThreadPanel({ actionId, title, params }) for each file. That does produce correctly-titled, deduplicated, persisted tabs — but it costs a permanent entry in the panel's Actions launcher next to "Start side chat" (there is no hidden variant), needs an empty state for when it is activated from there with params: null, and does not work on the root compose surface where openThreadPanel returns false. Paying that for a tab label seemed like the wrong trade, so my plugin swaps in place and documents the stale title as a known wart.

Related: #1959 asks for a first-party file tree panel in the thread sidebar. Worth noting that a plugin can already build most of that — tree, filter, expand/collapse, reveal the open file — and the thing blocking it from behaving like the real product is exactly this API gap. Closing this would let plugins serve that request without BB shipping the panel itself.

Found in bb thread thr_nnk8m7d8gw; see also #2026, #2072, and #2093 from the same work.

AGENT GENERATED: by Claude Opus 5