Contents

The showrunner chat, around the person's own Claude

Status: designed 2026-10-15; built slice by slice (session protocol 1.19). Slice 7, the card in Claude's chat and Ask in Claude Code, designed 2026-10-18.

The owner's ask, 2026-10-15: "The feature of redoing the ai assistant (aka the "Showrunner" chat panel) should be redone to work masterfully with a users claude connector interactions." Their standing rules: every AI feature works through the person's own Claude over MCP (claude.ai's connector, Claude Desktop, Claude Code, the plan through the helper), and a key is only ever an option. And from before: "Claude in Studio as easy as Brickworks."

Read with docs/design/claude-presence.md (who is on the show, protocol 1.15), docs/design/director-over-mcp.md (work left waiting for Claude, protocol 1.17), docs/audits/claude-setup-2026-10.md (the chat's way in), m12-remote-mcp.md and m12-plan-bridge.md.

The bar

Today the panel is Studio's own chat. When the person works with Claude somewhere else, Studio shows a toast for each proposal and a line in the header, and nothing else: not what Claude read, not what it is doing now, not its answer. A person on the web with no key and no helper cannot talk in the panel at all.

The redone panel makes it not matter where they talk:

1. One conversation, wherever it happens. What their Claude does to the show shows in the panel as it does it: what it read, what it proposes (approve, reject or undo right there), the stills of shots it re-directed, in plain words, naming which Claude and where.
2. Talking in Studio uses their Claude. On the desktop it runs Claude Code on their plan (built). On the web it goes through the helper (built), or Studio hands the ask to claude.ai and the answer comes back into the panel.
3. Shared context. Where the person is in Studio is what "this" means to their Claude anywhere (built: studio_context), and it is also a resource and part of every prompt.
4. Reelwright's prompts in Claude Code (the / menu, or /mcp__reelwright__here typed) and claude.ai, the same actions as the panel's one-tap ones.
5. An honest header: which Claude, where, whether it is working right now, and what to do when it is not. "Refused" only ever about a key.

What each Claude really supports (checked 2026-10-15)

Designed only on what works today. Sources: Claude Code's MCP page, deep links and channels reference; Anthropic's Build an MCP server for Claude, MCP Apps and plugin support; the repo's docs/audits/claude-connection-audit-2026-10.md (the real Claude Code 2.1.296).

What follows from it:

• Nothing can make Claude speak first. No client lets a server start a turn (no sampling; channels are a preview behind a dangerous flag). So "talking in Studio" is either Studio's own chat on the person's plan (Claude Code here, or the helper), or a hand-off the person sends in Claude. The design never waits on a feature that is not there.
• A server never sees Claude's words to the person. What Studio can show of a Claude outside is what it did through Reelwright. Its answer reaches Studio only when it says it through Reelwright: the hand-off asks it to (answer_in_studio, below).
• A prefilled claude.ai link is a bonus, not the path. The hand-off copies the ask too, and the ask waits in Reelwright, so the words in the link are only a pointer to it.

What exists, and stays

• Studio's own chat (RwChatPanel): turns, streaming, tool lines, proposal cards with Approve, Reject, Review and Undo, variation groups, places to go, suggestions, cost. It runs on a key, on the plan through Claude Code here (serve --claude-plan, PlanChat), or on the web through the helper (reelwright claude bridge).
• The way in (RwClaudeSetup): the person's own Claude first, the key last and folded (claude-easy-4).
• Presence (protocol 1.15): session.agents, the change's via, the toast, the header line. Studio's own chat on the plan is not an AI from outside (agent.chat, --studio-chat), nor is its work there (--studio-work, which still names Claude Code on what it proposes).
• Work left waiting for Claude (1.17): .reelwright/studio/asks/, session.asks, direct_episode with an ask taken by the connected Claude.
• studio_context: where the person is, from chat.focus, with that page's brief.
• The ChangeSet schema: unchanged. ChangeSet 1.4, reserved for this, is not needed and goes back.

The panel, screen by screen

The panel keeps its place and its parts: a header, one conversation, the message box. What is new is in each.

The header: "Your Claude"

The two lines under the title ("Connected: …" with Check, and "Claude is connected through claude.ai") become one list, one line per Claude that can work on this show, the one Studio's chat uses first. Each line is a dot, the words, and at most one action.

When something is wrong the line turns red and says the one thing to do, in place of the action:

"Refused" is said only of a key. No Claude at all reads "No Claude connected yet", and the way in is under it, as now. A viewer of a shared show sees no list. More than two lines fold into "and 1 more", which opens them.

The conversation: Studio's turns and Claude's visits, in the order they happened

Studio's own turns are as now.

A visit is what a Claude outside Studio did on the show, from its first call to a minute and a half of quiet. It is a block of its own in the conversation, between whatever came before and after it:

 ✦ Claude · through claude.ai                         4:02 PM  ◌ working
   Looked at where you are in Studio: Cast › Otto
   Read Otto
   Read the show's memory
   ┌ Proposal · Make Otto older ─────────────────────────────┐
   │ otto · 3 fields · 2 previews                            │
   │ [model sheet before] [model sheet after]                │
   │ [Approve] [Reject]                           Review ›    │
   └─────────────────────────────────────────────────────────┘
   Claude's reply is in claude.ai.  Open claude.ai ›

• Its head names the Claude and where ("through claude.ai", "through Claude Code", "in the Claude app"), when it began, and "working" while a call runs or one ended in the last 20 seconds.
• Each thing it did is a line in plain words, drawn by the core so Studio can say it in Spanish: "Looked at where you are in Studio: Cast › Otto", "Read Otto", "Read the theme", "Drew a preview of the bridge", "Looked at what waits for your review", "Directing The Lighthouse, scene 2 of 5". A call that failed says so after it, quietly ("couldn't: no such character"). More than six lines fold into "and 9 more".
• Each proposal is the chat's own card, with Approve, Reject, Review and Undo, its variation options to pick from, and its previews. Deciding it here is the person's own decision, as everywhere. An episode Claude re-directed shows the stills of the shots it changed, before and after (slice 5).
• Its answer, when it gave one through Reelwright (a hand-off, below), is a reply in the block, as the showrunner's are: Markdown, places to go. Otherwise the block ends "Claude's reply is in claude.ai" with Open claude.ai (the web; Claude Code's is in its terminal and says so).
• When it goes quiet: "claude.ai stopped working on the show · proposed 2 changes".
• The toast "Claude, through claude.ai, proposed: …" stays for when the chat is folded or out of sight (another page on a phone): with the chat open, the card is the news.
• A visit is kept with the show's conversation, as the turns are, and comes back with it.
• On the web, a person sees their own Claude's visits; a collaborator's Claude shows as its proposals, as now.

A hand-off (below) is the person's message with a line under it:

                                           ┌──────────────────┐
                                           │ Make Otto older. │
                                           └──────────────────┘
   ◌ Waiting for Claude in claude.ai · Open claude.ai again · Copy · Cancel

then "claude.ai is on it", and the visit that answers it grows under it.

The message box: talking here, always to your Claude

Ask in claude.ai (the web, and a show on Reelwright in the installed Studio):

1. Studio leaves the ask waiting in Reelwright: the words, and where the person is (chat.ask).
2. It copies, and opens claude.ai in a new tab with, one line: In Reelwright Studio I asked: "Make Otto older." (Reelwright ask cask_…: take it with studio_context, then answer me in Studio with answer_in_studio.) claude.ai may type it in the message box for them; if not, they paste it. The panel says which: "claude.ai is open with your ask. If its box is empty, paste (Ctrl+V)."
3. They send it in claude.ai. Their Claude, with Reelwright connected, calls studio_context, which hands it the waiting ask with the place it was asked from, so "this shot" is that shot. Studio says "claude.ai is on it".
4. What it does fills the visit under the ask, live. It answers with answer_in_studio, which the rules ask of a Claude that took an ask from Studio, and the answer is its reply in the panel.

Ask in Claude Code (the desktop, when the person keeps the chat off their plan): the same ask, and claude-cli://open?cwd=<the show>&q=<the line> opens Claude Code in a terminal in the show's folder with the line typed, for them to send (slice 7, below: once Studio knows Reelwright is added there; until then the line is copied). "Chat using my Claude plan" stays the first way there: the chat itself runs Claude Code, with nothing to switch to.

A phone opens claude.ai in the Claude app where the system hands it the link, else the browser.

Cancel takes the ask back. A newer ask takes the place of one still waiting. An ask nobody took in a day goes.

The way in

claude-easy-4's way in stays. Two additions: on the web, once the account has a claude.ai connection, the way in steps aside for "Ask in claude.ai" (the message box above), and it names the prompts once Claude is connected, under "Use Reelwright from Claude" and short, so the visit above stays in sight ("In Claude Code, type /mcp__reelwright__here."; "In claude.ai, Reelwright's prompts are under +."), and Settings › Claude says it whole.

Desktop, web and phone

• Desktop, a show of this computer: Studio's chat on Claude Code here first. Claude Code in a terminal, or Claude Desktop with reelwright mcp, show as visits (presence files). Ask in Claude Code when the chat is not on the plan.
• Desktop, a show on Reelwright: as the web, through the account.
• Web: Studio's chat through the helper, or a key; else Ask in claude.ai. claude.ai, Claude Desktop, Claude mobile and Claude Code on the service's /mcp show as visits.
• Phone (390 wide): the chat is the sheet from the bar at the foot. The header's list is one line ("claude.ai · working now", the rest folded). A visit's lines wrap; its cards are the chat's, which fit a phone. Ask in claude.ai opens the Claude app or a tab.
• Spanish: every word Studio shows goes through RwLang; every line the core draws comes with its said, as the core's other sentences do (protocol 1.8).

Protocol and MCP (session protocol 1.19)

All additive and optional. A client before 1.19 never asks for the new things and reads past them. Each slice adds its part to the unreleased 1.19, as claude-easy-4 did to 1.15.

What a Claude outside does (slice 1)

• The MCP server says what it does. mcpHandlers (both protocols, desktop and service) takes onActivity, and tells it, for each call: call (callId, tool, kind, the line in English and its said), result (ok, and the first line of a failure), and proposal (the ChangeSummary) for each change a call proposed; read for a resource read; context for studio_context. The line is drawn from the tool's kind and its input's target by the core (activityLine), with the document's name read from the show, never the input's own words.
• On this computer, reelwright mcp keeps its newest 40 in its presence file (.reelwright/studio/agents/<pid>.json, recent, numbered), written whole each time. The daemon reads the folder each second (as now) and tells each one once, by its number. Not for --studio-chat, whose work is the chat's own, nor --studio-work, which Studio shows itself.
• On the service, the show's link (ShowLink) sends each one to the daemon as agent.activity (a method only an AI's link may call; any other connection is refused, session.not_agent). Not for a chat link (agent.chat).
• The daemon tells Studio agent.event: {agent, client, person?, seq, at, event}, to the Studios of the person it works for (on the desktop, every Studio). seq counts per agent.
• Studio keeps them in the conversation's thread, as it keeps chat.event.

Asks from Studio's chat (slice 2)

• chat.ask {text, context?} → {ask, line} (the class of chat.send: a viewer may not). It leaves the ask in .reelwright/studio/chat-asks/<id>.json (the words, the place, who asked, when), the person's newest in place of one of theirs still waiting. line is what Studio opens claude.ai with, and copies: the person's words, then the ask's id and how Claude takes it. chat.unask {ask} takes it back, the asker's own only. A store of its own, not 1.17's directions: session.asks keeps its shape for the clients that read it now.
• chat.asks, a notification to a Studio that says 1.19, its own person's asks only (on the desktop, all): each waiting or taken, by which client, since when. Sent when it changes, read each second as session.asks is, and once the hello is answered. An ask taken by a process that is gone, or taken half an hour ago and never answered, is given up.
• MCP: studio_context leads with the person's newest waiting ask, its words and the brief of where they were as they asked, and takes it (the file becomes <id>.taking.json, naming the client); called with ask it takes that one. answer_in_studio {ask, text}, a tool of every server's own (as studio_context is), listed where Studio can hear it: its text (at most 4,000 characters, the chat's Markdown, reelwright: links) becomes an answer activity, and the ask is over. The rules, the tool descriptions and the line itself tell a Claude that took an ask from Studio to answer it so, once, at the end. The prompt asked brings the waiting ask to a client that offers prompts.
• Studio: with no Claude for the chat and a daemon that speaks 1.19, the message box takes the ask ("Ask your Claude…", Send is "Ask in claude.ai"). The ask's line under the person's message says where it is (waiting, "claude.ai is on it", answered, no answer here, taken back), with Open claude.ai again, Copy and Take back while it waits. The answer is in that Claude's visit, as the showrunner's replies are. On the desktop with a show of this computer the line is copied, to paste to Claude Code or the Claude app (Ask in Claude Code, through claude-cli://, came with slice 7, once Studio knows Claude Code is there with Reelwright added).

Prompts and the place as a resource (slice 4)

• Prompts on both servers (prompts capability; prompts/list, prompts/get; core/src/mcp/prompts.ts), each one of the panel's own actions, the person's own message, each carrying where they are (the page's brief), and each telling their Studio a line of what their Claude looked at (agent.event). None takes an argument: Claude Code gives an argument only the first word typed, and drops a command whose required one is missing, while Claude reads the person's whole words beside the prompt.

  Prompt	Its message
  here	the place's brief, and that the person's words come with it or next
  suggestions	what Studio's chat suggests asking there, for Claude to pick one and do it
  asked	the person's newest ask from Studio's chat, as Studio's hand-off line says it, shown and not taken (studio_context takes it); then the directions Studio left waiting (1.17)
  review	what waits for their review, each with why and its diff, and that deciding is theirs
  next	the show's next steps, as the Show page lists them, each with the tool that does it

• reelwright://studio, a resource: where the person is in Studio now, as studio_context answers it.

• No session change: the MCP servers read the place and the asks as studio_context does.

Stills of re-directed shots (slice 5)

No protocol change: episode.timeline of a change and previews.get kind still with the change as its target exist. The card asks them for the shots the change touches.

The card in Claude's chat, and Ask in Claude Code (slice 7)

The owner's plan, item 9 (docs/audits/product-audit-2026-10f.md): "Approving Claude's work means coming back to Studio." Someone who works with Reelwright from claude.ai sees Claude's proposal there only as words, and comes back to Studio for the stills and Approve. claude.ai, Claude Desktop and Claude mobile show MCP Apps (the extension, spec 2026-01-26), so Reelwright gives them the panel's card. No session protocol change: the card works through MCP, and its decisions are the decide tools the person already has. Session protocol 1.22 is not needed.

The app. One resource, ui://reelwright/proposal (text/html;profile=mcp-app, core/src/mcp/app.ts), listed and read on both servers (reelwright mcp and the web service's /mcp, both protocols). It is one HTML page with its script and style inline, the card's words in English and Spanish (the host's locale), its colours the host's theme. It asks for nothing outside its frame: no csp, so the host's default holds (no network; pictures as data: only).

• Every propose tool offers it: its listing carries _meta.ui.resourceUri. Its result is as now: the proposals in words and their previews for Claude. Nothing is added to the result (structuredContent would take the words' place in Claude Code), except _meta ["reelwright/changes"], the proposals' ids, for the card; the card falls back on the "Proposal chg.…" lines of the text.
• Two tools for the card alone (_meta.ui.visibility: ["app"]: the host never gives them to Claude), read-only, listed where the person can propose, and never told to Studio's chat as something Claude did:
  • proposal_card {changes}: each change's title, status, who proposed it and through which Claude, its rationale, what it changes per document (each field's label, before and after), its warnings, its first two previews as JPEG; for one change that re-directs an episode, the shots it changes (the episode compiled now and as the change has it, told apart as RwShotChanges does: new or changed shots first, then those of a scene whose performance changed, at most two), each with its middle frame now and before; where Studio opens it (the web service: <base>/studio/#/<show>/change/<id>); and the show by the id a 2026-07-28 call names it with.
  • proposal_still {change, frame, before}: one still of the episode the change re-directs, at that frame, as it is (before) or as the change has it, drawn as render_preview draws it (and cached with Studio's own card's), as one JPEG.
• The card: "Proposal", its status, the title, what it touches ("Lighthouse cold open · 3 fields"), the warnings, the previews, "The shots it changes" with Before and After of each (a spinner while each is drawn, "Couldn't draw it" when it failed), then Approve, Reject and Open in Studio. A variation group lists its options, each with Pick. Approve and Reject call approve_change and reject_change through the host, on the same connection: the person's own decision, as Studio's buttons are (on the service, the person's own change.approve over their link). The card then says "Applied" (with "Undo it in Studio") or "Rejected. Nothing was changed.", or why it was not applied, in place of the buttons. Open in Studio opens the change's page there (ui/open-link); with no address (reelwright mcp in Claude Desktop, whose Studio is an app) it is not shown.
• Studio's chat: the visit shows Claude's proposal card as before, and the decision made in Claude's chat reaches it as every decision does (change.event): it turns Applied. The visit's line says "Approved a proposal", as for any decide call on that connection.
• Claude Code shows no apps: it reads the result's words as now, and may list the two card tools, which only read.

Ask in Claude Code. On the desktop, with no Claude for Studio's chat, an ask handed off opens Claude Code with it once Studio knows Reelwright is added there for the show (reelwright claude status --show, connected and current, read as Settings › Claude reads it). Until then it is copied, as before.

• reelwright claude open --show <dir> --ask <line> runs the Claude Code it finds (as every claude action does, REELWRIGHT_CLAUDE first) as claude --handle-uri claude-cli://open?cwd=<show>&q=<line>: what the link handler Claude Code registers runs (claude-code-url-handler.desktop on Linux, its app on macOS, HKCU\Software\Classes\claude-cli on Windows). So it does not wait for that handler, which Claude Code registers only after a first prompt typed in it, and it opens the Claude Code Studio checked, never another one. Claude Code opens its own terminal in the show's folder with the line typed, under "Prompt from an external link", for the person to send. A line over 5,000 characters (the link's limit) is not opened.
• Studio copies the line too, then opens it. The ask's line says "Claude Code opened with your ask typed in. Press Enter there to send it.", with Open Claude Code again; when it did not open, why, and that the ask is copied.

Proof. Core: mcp-app.test.ts (the resource listed and read on both servers and both protocols; the propose tools offer it, no other; the card's tools are app-only, listed only where the person can propose, untold; proposal_card gives an episode change's shots and its Studio address, and a character change's previews; proposal_still draws before and after); the claude open --ask case in claude.test.ts (the launch is the found claude with --handle-uri and the encoded link; too long is refused). Engine: rw_chat_panel_test.gd (with Reelwright added in Claude Code, a hand-off asks Studio to open it and the line says so; without, it is copied). A web check, tools/web/claude-app-check.ts, with no key: a scripted claude.ai lists the tools and re-directs a shot; a page acting as the host reads the app's resource and shows it in a sandboxed frame under the default CSP, passing it the call's input and result and its calls through to the server; the card shows the shot's stills before and after; Approve on it applies the change (the episode's file holds it), and Studio's chat shows the card Applied; Open in Studio asks to open the change's page. Mutations: the card shows no stills (proposal_card gives no shots); Approve does not apply (the card's Approve calls nothing).

The slices, in order

Each is provable on its own: core tests, an engine test, the web check (and the desktop watch) that covers it, and a mutation for each guarantee. Each carries its Spanish, its CHANGELOG lines, its docs and the verify skill's entries.

1. Claude's work from outside, live in the chat. onActivity, the presence file's recent, agent.activity, agent.event; the panel's visit blocks with the chat's cards; the toast only while the chat is out of sight. Proof: mcp-server.test.ts (each kind reported, stdio and both service protocols), session-daemon.test.ts (a link's activity reaches its person's Studio and nobody else's; a file's reaches every Studio once; a chat link's and --studio-chat's none; another connection's agent.activity refused), rw_chat_panel_test.gd (the block, its words, its card decided in place, kept and brought back, Spanish), tools/web/claude-outside-check.ts (a scripted claude.ai reads and proposes; the panel shows each line live; Approve on the card applies it; 390 wide), tools/claude-outside-watch.sh (the same on the desktop through reelwright mcp). Mutations: no broadcast; the file's recent unread; the block not drawn.

2. Ask in Studio, answered by your Claude in claude.ai or Claude Code. chat.ask, chat.unask, chat asks in session.asks, studio_context takes one, answer_in_studio; the message box's Ask in claude.ai and Ask in Claude Code, the waiting line, the answer in the visit. Proof: core tests (an ask taken once, by one client; answered; a newer ask in place of one waiting; a viewer refused; a 1.18 client sent no chat ask), the engine test, a web check with no key and no helper (Studio asks; the link opened and the line copied are the expected ones; a scripted claude.ai takes it, proposes and answers; the reply and the card come into the panel; Approve applies it). Mutations: the ask not taken; the answer not told; the box's Send still disabled.

3. An honest header. The ways list (RwClaudeWays): the chat's way and its state, each Claude outside and its state (live from 1 and 2; the account's connections on the web, claude status --show on the desktop), the one action each, the red lines with what to do, no "refused" without a key. Proof: an engine test over the table's every row, in Spanish too; the web check of 1 extended with the header's states (connected idle, working now, helper stopped); claude-setup-check.ts's header asserts updated. Mutations: one per row family.

4. Reelwright's prompts and the place as a resource. Proof: mcp-prompts.test.ts (in process and over stdio) and host-mcp.test.ts (2025 and 2026-07-28) with the SDK's clients: listed, got, each carrying the place Studio said; tools/web/claude-prompts-check.ts (Studio's way in names them, a scripted claude.ai gets them on Otto's card); the real Claude Code over stdio (tools/claude-real/prompts-check.ts); the engine tests of the way in and Settings › Claude naming them; the web check of 2 has its scripted claude.ai start with prompts/get asked. Mutations: the place left out of here and of the others; asked without the ask, or with another person's; review without the diff; next without an episode's step; the resource, the capability, the 2026 handler, the daemon's episodes.status; the way in's line, its claude.ai part, its ways, Settings' step.

5. Stills of re-directed shots on the card. An episode change's card (Studio's own turns and visits alike) shows the changed shots' stills, before and after, at most four, drawn once. Proof: the engine test (the shots asked for are the changed ones), a web check where a scripted claude.ai re-directs a shot and the card shows its stills (lavapipe). Mutation: every shot asked for, or none.

6. Your own Claude first. With no Claude of the chat's own and a daemon that hands asks on (1.19), once a Claude outside is connected the way in folds from the start to its one line, under the prompts line; the suggestion chips show and hand off; the hint under the box says where Enter sends the ask. Chosen over the list below: what a person with claude.ai connected and no key met first in Studio's chat was a card asking for an API key and nothing to press. Proof: rw_chat_panel_test.gd "with the person's claude connected the chat is its first", claude-outside-check.ts and claude-prompts-check.ts (the fold line, the hint).

7. The card in Claude's chat, and Ask in Claude Code (plan item 9, above). Proof as above.

Why this order: 1 is what every other slice shows its work in. 2 is the biggest gap for a person on the web with no key and no helper, who today cannot talk in the panel at all. 3 waits for claude-easy-4's way in and header to land, which it changes. 4 and 5 stand alone.

Not built, and why

• Pushing Studio's message into a running Claude Code (channels): a research preview that needs an approved plugin or a dangerous flag, and works over stdio only. When Reelwright can be on the allowlist, Ask in Claude Code could go straight into a running session.
• Sampling (Reelwright asking the person's Claude to answer): no Claude client supports it.
• Undo on the card in Claude's chat: the card says "Undo it in Studio". An undo from Claude's chat would be a decision made on a card that may be hours old; Studio's chat and History show what came after it.
• A Reelwright plugin (the connector with skills, installed from claude.ai and synced to Claude Code), and a Connectors Directory listing: both need a submission and Anthropic's review: the owner's to decide.
• Claude's words to the person outside a hand-off: no client gives them to a server.
• The full ways list in the header (one line per Claude with its own dot, action and red line, RwClaudeWays): slice 3 built the part that was missing, "· working on the show now" on the outside Claudes' line while one is at work (RwChatPanel.set_outside, working_sec). The chat's own way already says its trouble in the person's words (claude-easy-4's lines), and Settings › Claude lists every way; one list for both waits for a second look at the header as a whole.
• Ask in Claude Code before Reelwright is added there: the ask is copied instead; opening Claude Code without Reelwright would hand the ask to a Claude that cannot take it.