Desktop: read a private chat's knowledge selection with the user's proof (KB chip, / palette, workflow capture)

[Broccolito]

What was wrong

GET /knowledge/active naming a chat is on the reach gate's list in session_reach.rs, exactly like the POST beside it. The write (setActive in KnowledgeContext.tsx) has always sent userActionHeaders(). The reads did not. They are the KnowledgeProvider hydrate and its recovery re-read, the / palette's knowledge-base rows (MentionPopover.tsx), and the create-workflow modal. So the desktop's own daemon answered each read as a public caller and refused every private chat, whatever model was bound.

Measured on the desktop (2026-09-11)

This ran in a sandboxed dev instance on versa_azure (GPT-5.5). One turn ratcheted a new chat to private. Its selection was then set, with the proof, to primary lab-notes and grant-drafts hidden. That stands in for the agent's kb_set_active, the CLI, or another window changing it.

	Before	After
GET /knowledge/active?session_id=…, no headers	403: "That chat is private, or there is no chat with that id. This request was made on a public model…", for a chat bound to a private model	(unchanged; the renderer no longer sends this)
Same request with X-User-Action	200, the chat's selection	200, the chat's selection
Console on opening the chat	Knowledge selection not hydrated: That chat is private, or there is no chat with that id.	nothing
KB chip	3 visible, Grant drafts switched on (the renderer's cache)	2 visible, Grant drafts off
One click on Soul in the chip	daemon ends with hidden_kbs: ["soul"], so Grant drafts is visible to the chat again	daemon ends with hidden_kbs: ["grant-drafts","soul"]
/kb palette	offers kb:Grant drafts as "Knowledge base in this chat"; names no primary	Lab notes as "Primary knowledge base", plus Soul

The fourth row is the reason this is more than cosmetic. A set-only edit is computed from the set the renderer holds, so a refused read turns the next toggle into a silent overwrite of the chat's real selection.

Decision: these reads carry userActionHeaders(), like getSession and reply

• Nothing new is reachable. The same proof already reads the chat's whole transcript through getSession, which discloses far more than which knowledge bases the chat uses. The write beside these reads already sends it.
• The renderer is the person at the keyboard. That is the premise of userActionHeaders(), and the gate's own module doc names it: the proof is how "the desktop app reaches a private chat it has open on a public model".
• One helper decides the surface. userActionHeaders() is where the surface is resolved, so these reads pick up the browser half with no further change once SD-9's change to the helper lands (fix(serve): a new chat starts on the host's configured private model (QA F1) #229). I checked this by merging fix(serve): a new chat starts on the host's configured private model (QA F1) #229 into this branch in a throwaway worktree (not committed):
  • with both, a browser-surface hydrate of a private chat sends X-Caller-Provider: versa_azure and settles, and fix(serve): a new chat starts on the host's configured private model (QA F1) #229's own userAction.surface.test.ts still passes;
  • with fix(serve): a new chat starts on the host's configured private model (QA F1) #229 alone, the same test reproduces the reported serve console line: "Knowledge selection not hydrated: This daemon was started without a user-action key…".

Left alone on purpose: refreshDefaultPrimary's machine-scope getActive. It names no chat, and the gate is inert there ("Machine-wide selection requests name no chat and remain outside the session boundary").

The comment

KnowledgeContext's catch arm called the refusal "a correct outcome" for "a private chat opened while a public model is bound". Neither half held:

• the read was refused for every private chat, measured with the chat on its own private model;
• what followed was not correct, as the table above shows.

The comment now says so, and names where a refusal is right: a caller with neither the proof nor a private model, meaning a daemon started without a user-action key, or a browser tab not running a private model. selectionWarning.ts and its test carried the same premise and are corrected in a separate docs commit. Their one-line console trimming is unchanged and still right.

Changes

• components/knowledge/KnowledgeContext.tsx: the proof on the hydrate and on rehydrateSelection; the corrected comment.
• components/MentionPopover.tsx, components/workflows/CreateWorkflowFromSessionModal.tsx: the proof on their getActive. Both keep their Promise.all parallelism.
• test/reachGate.ts (new): one model of the gate as a renderer test meets it. A private chat is answered only with the proof, and a refusal is delivered as the generated client delivers this route's text/plain 403.
• Tests. All five new ones fail with the production change reverted:
  • KnowledgeContext.test.tsx: the hydrate, the recovery re-read, and the toggle that re-exposed a hidden base;
  • MentionPopover.privateChat.test.tsx (new): the palette's rows and primary label;
  • CreateWorkflowFromSessionModal.test.tsx: the captured knowledge_bases (it saved default: soul and all three bases).

Verification

• npm run test:run: 443 of 443 files, 4974 passed, 1 skipped.
  • An earlier run, made while a dev GUI was building on the same machine, hit two failures that don't recur: the known Ollama teardown rejection (OllamaInlineCard.tsx:41 in ProviderCatalog.test.tsx) and a 30 s afterAll in artifactCdnAssets.browser.test.ts. That file passes on its own, and the full run above is clean.
• The five new tests pass 10 of 10 on repeat runs; no new act() warnings.
• npm run lint:check passes: typecheck, ESLint, themes, 332 contrast assertions, tokens.
• npx prettier --check passes on all nine changed files.
• The create-workflow modal was verified by its unit test only. In the app, a successful generation usually carries the daemon's own knowledge-base block and overwrites the modal's read. The modal's read decides the capture when the generation brings none.

Not in this PR

• When the read genuinely fails (network, older daemon), the palette and the modal still fall back to "nothing hidden, nothing primary". With the proof attached that is now only a real error, but a failed read still reads as a claim about the chat.
• The chip re-reads the selection when a chat opens, not when something else changes it mid-chat.

🤖 Generated with Claude Code