[BUG] Dispatch missing from Claude Desktop sidebar on Linux 1.24012.9 — visible on Android, same Pro account

Adding a cross-platform data point: this is not Linux-specific.

#80058 reports the same symptom on macOS (Desktop 1.24012.1, Team plan) — Dispatch works on mobile, unusable on desktop. Critically, that reporter has a teammate on the same Team plan with the same role whose desktop shows Dispatch normally, while theirs does not.

Taken with my report, that rules out:

Operating system — occurs on both macOS and Linux
Plan tier — occurs on Pro (mine) and Team (#80058)
App version — 1.24012.1 and 1.24012.9
Org policy — same org, same role, different outcome

What's left is per-account server-side gating of the Dispatch surface.

Supporting detail from my Linux client: there is no pairing state file anywhere under ~/.config/Claude/ — no Linux equivalent of the bridge-state.json whose absence is noted in #80058. Meanwhile main.log does receive dispatchCuGrantTtlMs entries in the computer-use config block, so Dispatch-related config reaches the client while no UI is rendered.

Flagging that #39549 (same underlying complaint, macOS) was closed as invalid. If Dispatch-in-Desktop is out of scope for this repo, could that be stated explicitly so reports get routed to the right place rather than going stale?

Still reproduces on Claude for Linux 1.30096.1 (194d93), Ubuntu 26.04, Pro plan.

Filed originally against 1.24012.9. Many stable releases later, the Cowork (Home) left panel still contains only:

New · Projects · Artifacts · Scheduled · Customize

No Dispatch entry. Dispatch continues to render normally in the Android app on the same account, so the entitlement is still present server-side and the desktop client still never draws the surface.

With #84522 (Windows, Pro) now filed alongside #80058 (macOS, Team) and this report (Linux, Pro), the symptom is present on all three desktop platforms, across Pro and Team, and across several app versions — while mobile works on every one of them. That points at per-account gating of the desktop Dispatch surface rather than anything platform-specific.

Could someone confirm whether that surface is gated per-account, and whether these reports are in scope for this repo?

@stephenmhutchinson-design — answering your question about whether the desktop Dispatch surface is gated per-account, with a controlled test posted in #80058.

Two personal Max accounts on one MacBook Air, one Claude Desktop install: account A has no Dispatch entry, account B has Dispatch · Beta. Switching between them (Cmd+Q and relaunch each time, sidebar state visually confirmed before each capture) and diffing the renderer's launch flags:

ps auxww | grep -o "desktop-features=.*" > /tmp/a.txt
ps auxww | grep -o "desktop-features=.*" > /tmp/b.txt
diff /tmp/a.txt /tmp/b.txt && echo IDENTICAL

Result: IDENTICAL, byte-for-byte across ~60 keys.

Two things that bear directly on your Linux report:

1. These flags don't govern the sidebar. This build reports "artifactsPane":{"status":"unavailable"} and "coworkArtifacts":{"status":"unavailable"} while Artifacts renders in the sidebar on both accounts. There is no dispatch-named key anywhere in the list. So the flag cache is the wrong place to look — which matches your finding that the codenamed flags in cowork-gb-cache.json yielded nothing identifiable.

1. operon is a dead end. #45962 identified it as the likely Dispatch gate before being auto-closed as a duplicate and locked. It no longer exists in current builds at all.

Your dispatchCuGrantTtlMs observation is consistent with this: Dispatch-related config reaches the client while the nav entry is never drawn, so the two are delivered by different paths.

Full detail and the maintainer questions are in #80058. Given this now spans Linux (here), macOS (#80058) and Windows (#84522) across Pro/Max/Team, it would help if these three were consolidated under one tracking issue.