Open plan reviews in the secondary panel instead of the cramped banner #4379

The workflow

A provider finishes planning and asks me to approve the plan before it implements it. I want to read the whole plan comfortably, then choose Approve plan or Keep planning.

What happens today

The plan approval appears as the Plan review banner above the composer (PlanReviewRequestBanner in apps/app/src/components/thread/pending-interactions/ThreadPendingInteractionBanner.tsx). The banner starts collapsed. When expanded, it renders the whole plan as text-xs markdown inside a small fixed-height scroll box, with the plan file path underneath.

Real plans (goal, implementation summary, steps, acceptance criteria, test strategy, risks) are long, so reading them in that box is cramped. There is no way to view the plan at a comfortable size before deciding. This affects every provider that sends a kind: "plan" approval with a planFilePath, including Claude Code plan mode and the Polytoken plugin's plan handoffs.

What you would expect

An Open plan button in the plan review banner that opens the plan file in the thread's secondary panel, rendered as markdown at full panel width:

• The button shows only when the banner knows the environment's host id and planFilePath is a valid absolute host path. Otherwise the banner keeps today's inline view without a button.
• Opening the plan does not approve or deny the review; the review stays pending.
• The plan opens with BB's built-in viewer (viewer: "builtin"). Otherwise a plugin that claims .md files, such as the Docs plugin, takes over and shows the raw markdown source instead of a rendered plan.
• Only the main thread's banner gets the host id for now. Banners for child-thread interactions are unchanged.

Approve plan and Keep planning behave exactly as they do today.

Context and alternatives

Related bug found while building this. ThreadDetailView's file-open handler (handleOpenLiveFilePreview) passes the whole AppFilePreviewIntent to normalizeExperimentalFileOpenOptions. That validator accepts only an object whose keys are exactly target and location, so any intent that also carries viewer returns null and the file never opens:

normalizeExperimentalFileOpenOptions({ target, location: null });                    // → { target, location: null }
normalizeExperimentalFileOpenOptions({ target, location: null, viewer: "builtin" }); // → null

viewer is a supported field of AppFilePreviewIntent, and the handler reads intent.viewer right after validating. The "Open with → BB preview" and "Open with → " items in ExperimentalFileLinkMenu send it. The exact-key check arrived in #2094 to harden plugin-supplied links, after #2005 added viewer, and appears to have broken the app's own viewer option by accident. The fix is to validate only { target, location } and keep passing viewer through. Plugin-supplied intents are still normalized in plugin-sdk-hooks.ts before they reach this handler, so plugin input is validated as strictly as before. RootComposeView and PluginPanelRightPanelHost use the same pattern; the prototype leaves them for a follow-up.

Prototype: main...samanthar0se:bb:plan-review-open-in-panel. It's a single commit on current main touching 6 files in apps/app, with tests for the banner (the button opens the host target with the built-in viewer without resolving the review, and no button appears without a host or with a relative path) and for the viewer validation fix. I checked it in a local BB instance with a real Polytoken plan handoff: the plan opened rendered in BB's preview with the Preview/Raw toggle, and the review stayed pending.

Out of scope: sending review comments back to the planner (Keep planning still cancels), opening plans automatically when a review arrives, plans without a file path, and the same validation pattern in RootComposeView and PluginPanelRightPanelHost.

Alternatives considered: a larger inline box still competes with the composer for space. Changing your own .md viewer preference to BB's built-in viewer works for you, but it changes every markdown file and doesn't help other users.

Checks

• I searched open and closed issues for the same request.
• If an agent wrote this, the body ends with > AGENT GENERATED.

AGENT GENERATED