[desktop] "Show background tasks" missing from Dispatch kebab menu until app relaunch (macOS)

Summary

In Dispatch (Beta) on the Claude desktop app, the kebab menu (⋮ next to the "Dispatch" title) intermittently omits "Show background tasks" while still showing "Clear background tasks".

That item is the only route to the expanded view exposing the model and reasoning effort controls. While it's absent, Dispatch loses its main granularity knob.

Updated 2026-08-23. Two claims in the original report turned out to be too strong and have been corrected in place: spawning is not a hard "never", and the item also disappears mid-process. The conclusion has been revised accordingly. Detail in the sections below and in the follow-up comment.

Impact

No model or reasoning-effort selection at all until the item returns.

Workaround

Fully quit the app (⌘Q — not just closing the window) and relaunch. The item is then present with zero tasks running.

What does NOT trigger it

Tested on macOS, all within a single app process, menu reopened after each task reached running state:

| Attempt | Result |
| --- | --- |
| One Cowork child session live | absent |
| Two Cowork children live | absent |
| A Code session live | absent |
| In-process subagent (~3 min) | absent |
| Three concurrent tasks of mixed kind | absent |
| Closing and reopening the menu with a task live | absent |
| Quit + relaunch, zero tasks running | present ✅ |

Every row above was reproduced repeatedly. However, with continued use since this report was
filed, spawning has occasionally revealed the item — a Cowork child or a Code session, either kind —
at roughly one attempt in twenty. So spawning is not a hard "never", it is a rare and unreliable
trigger. That figure is an impression from everyday use, not a counted experiment.

Process lifetime remains by far the reliable lever.

It also disappears mid-process

The item does not only fail to appear. It also goes away again spontaneously inside a single app
process, with no task started or stopped and no menu interaction in between. Quit-and-relaunch
brings it back, but that is not a permanent fix — it can go missing again later in the same process.

The asymmetry

"Clear background tasks" renders unconditionally; "Show background tasks" does not. The two items evidently have different visibility predicates.

Investigation

app.asar extracts cleanly and is readable, but:

• The literals "Show background tasks" / "Clear background tasks" do not exist anywhere in the bundle.
• .vite/renderer/main_window/index.html states it outright: "this is the html for app title bar and error UI. everything else gets loaded from claude.ai" — so the kebab menu is remote React, and its visibility logic never ships to the machine.
• The Electron main process exposes only popBackgroundTaskSuggestion / popBackgroundTaskSuggestionById, and carries losableBackgroundTaskCount / resolvedBackgroundTaskSuggestions. No menu-visibility flag.
• Local config has no background key. Statsig gate names in Local Storage are numeric hashes, so they can't be mapped back to feature names.

Conclusion (revised 2026-08-23): the visibility predicate is re-evaluated during process
lifetime, not pinned once at process start.

My original conclusion was a server-side gate evaluated once per app process, on the grounds that
relaunch was the only thing that ever worked. The two corrections above rule that out:

• A gate evaluated once per process cannot occasionally flip on during a spawn.
• A gate evaluated once per process cannot flip off mid-process with no user action.

Something re-fetches or re-evaluates the flag while the app runs. Spawning a task appears to be one
input that can trigger a re-evaluation, but an unreliable one, and some other input can take the item
away again. The bundle findings below still stand — the visibility logic genuinely is not on the
machine — so this remains a server-side question.

Prior art

• #69677 (Windows, closed as not planned) reports the same symptom, and claims the item "renders only when a background task is actively running". That condition is contradicted here: tasks of every kind were running and the item stayed absent; it then appeared after a relaunch with nothing running. That report likely observed a relaunch confound.
• #68992 and #70686 describe the inverse artifact — tasks stuck showing as "Running" after they finished.

Ask

• Is this a staged rollout, a flag being retired, or a genuine regression?
• Should this item be gated at all, given it is the only path to the model and reasoning-effort controls?

Environment

• macOS 26.5.2 (build 25F84)
• Claude desktop 1.32885.1 (CFBundleVersion 1.32885.1) at time of filing
• Still observed on 1.34493.1, the current build on the same machine (2026-08-23)
• Max plan
• Dispatch (Beta)