Web GUI: the access-level chip is clickable on New Session but its /permission picker silently does nothing (root cause + reference fix)

[almazom]

The bug: a visible control that silently does nothing

On the Web GUI's New Session screen, the composer shows the access-level chip (shield) derived from the session's permissions projection. Clicking it should open the /permission preset picker. It doesn't: the picker's decoration requires a materialized session binding, so on any unmaterialized surface available is false, options throws, and the click does nothing at all. One control, two availability sources — the visible half lies about the clickable half.

Once a session exists the same chip works fine, which makes the dead state harder to notice: the bug lives exactly where users configure permissions before starting.

Root cause

packages/client/ui-permission-presets/src/client/index.ts:

• available: session => selectOf(sessionFor(session)) !== undefined — sessionFor resolves through sessions.binding(sessionId)?.session, which is undefined for draft/unmaterialized sessions.
• the chip, meanwhile, renders from the permissions projection the host serves for these same surfaces — so it is visible exactly where the picker is not.

Reference fix (on our fork)

We understand external PRs are closed right now, so we published a complete, tested fix as a fork branch for reference:

https://github.com/almazom/deepseek-harness/tree/fix/permission-picker-unmaterialized-surfaces

The picker gains a second source — the host's permission settings namespace (the same descriptor the General settings row reads and writes):

• available is true when either the projection select or the permission settings namespace exists;
• without a materialized session, options reads the namespace's dynamic defaultPreset enum through permissionDefaultOf and presents it with the same localized labels, active mark, and Full access risk gate as projection rows;
• a pick on an unmaterialized surface writes the new-session default through the existing settings mutation — the current session is never touched; materialized sessions keep the /permission <preset> path;
• the plugin warms the settings mirror at apply; a host whose describe fails keeps the picker on the projection path only, which is exactly the current behavior.

Tests: a new browser-plugin case drives an unmaterialized session against a served permission namespace and asserts the labeled rows, the active default, and the settings/mutate write; the ghost-session cases are updated to the new contract. Focused suite: 16 files / 150 tests green; tsc -b and oxlint clean on the package. Bilingual README and an Agent Note are included in the branch.

Demonstration

Fix running on a scratch DSH_HOME (unmaterialized New Session surface throughout):

Recorded from the branch at 0622714 (build:web + source-launch CLI, headless Chromium, picker-only flow, no model round).

Happy to provide anything else that helps — repro details, a patch in another shape, or a discussion of the design. Into the unknown! 🐋

[almazom]

Follow-up — independent adversarial review of the reference fix

We ran a separate adversarial review (critic optics: breaks / scale / brittleness / gaps) over commit 0622714 and the companion statusbar-injection change. Verdict: SHIP WITH NOTES. Surfaces verified against source: the async options contract is handled by the popup shell (popup.ts fulfills and rejects paths), the settings-mirror never rejects (the fire-and-forget load is safe), and the label double-processing is idempotent for every input shape we constructed.

One real edge worth documenting (P2): available keys on the namespace view existing, while options additionally needs a well-formed defaultPreset value in permissionDefaultOf. A host serving the permission namespace with a malformed value would show the picker but fail the popup — loudly, with a retry, which is strictly better than the pre-fix silent no-op, and unreachable unless the host itself is broken. Noted as a follow-up: either tighten available or add a test pinning the loud-fail contract. Two smaller notes: the statusbar marker companion parses a human-readable aria-label (locale-fragile by design tradeoff, display-only when it misses), and the new test asserts the settings mutation but not the post-write fold.

Both follow-ups are tracked in our fork's task notes. Happy to iterate if the team prefers a different contract for the malformed-namespace case.