[BUG] Background computer use is silently disabled on macOS 27 by an undocumented version ceiling (26.x); Settings toggle is ignored and Claude still takes over the screen

Summary

The desktop app's new Background Computer Use (announced 2026-09-02) never activates on macOS 27. The main process gates the feature behind a maximum-macOS check that defaults to 26.9999, evaluated before the user's appScopedEnabled preference is read. On macOS 27 the check fails, the app_* tools are never registered, no "Take over the screen?" consent card is shown, and every click/type after a launch pulls the target app to the front exactly as before the feature existed.

The Help Center states background mode is "the default on macOS 15 or later" and lists no maximum version, so this is either a docs gap or an unintended cap.

Environment

• Claude Desktop 1.46388.3 (current per downloads.claude.ai/releases/darwin/universal/RELEASES.json on 2026-09-04); the live repro below was run on 1.46388.1 and the identical gate is confirmed present in 1.46388.3's app.asar
• macOS 27.0 beta, build 26A5425a, Apple M5 (arm64), 32 GB
• Plan: Max
• Computer use preference: on (chicagoEnabled: true in claude_desktop_config.json)
• Accessibility and Screen Recording granted; computer use itself works in full-screen mode

Steps to reproduce

1. On macOS 27, open a Claude Code session in the desktop app.
2. request_access for TextEdit (granted, tier full).
3. open_application("TextEdit") → a window is created and Claude stays frontmost. (Good so far.)
4. computer_batch with one left_click on "New Document" and one type action.
5. Check the real display (an unsandboxed screencapture, not the tool's own screenshot).

Expected

Per the announcement and the tool descriptions in the build ("Click within one window of a granted application without bringing it to the front"), TextEdit receives the input while the user's frontmost app is unchanged. app_click, app_screenshot, app_type, app_key are registered for the session.

Actual

• TextEdit becomes frontmost; the user's Claude window is pushed aside. Verified by screencapture and by System Events (frontmost = TextEdit).
• app_* tools are absent from the session. Only computer_batch, open_application, request_access, list_granted_applications, switch_display are exposed.
• list_granted_applications returns no coordinateMode field although its description says it does.
• No "Take over the screen?" card is ever shown.

Root cause (from reading app.asar, 1.46388.1)

The gate (minified QR) short-circuits on OS version before consulting the preference:

function QR(e={}){
  let t=e.requireFreshGrowthBook??!0;
  if(process.platform!=="darwin")return!1;
  let n=Lk();                      // Lk() = process.getSystemVersion() → {major,minor}
  if(n.major<15)return!1;
  let r=Zhn();                     // Zhn() = {major:TS(Khn,"major",26), minor:TS(Khn,"minor",9999)}
  return n.major>r.major || n.major===r.major&&n.minor>r.minor || t&&!KR()
    ? !1
    : TS(GR,"appScopedEnabled",!1,k())
}

• GR = "1291166712" (GrowthBook chicago_config), Khn = "1346958739" (the ceiling key).
• Defaults are major: 26, minor: 9999. macOS 27.0 → 27 > 26 → false → legacy display-scope mode.
• The hidden dev-menu override chicagoAppScopedDebugOverride is only read by the menu's own label (mgn()); QR never consults it, so it cannot lift the ceiling.
• The startup diagnostic [chicago] GrowthBook chicago_config: … appScoped=%s should log appScoped=false on any macOS 27 machine, which is the quickest confirmation on your side.

The app's own diagnostic confirms it (1.46388.3, fresh boot 2026-09-04 16:40)

From ~/Library/Logs/Claude/main.log, one line, unedited except for wrapping:

2026-09-04 16:40:25 [info] [chicago] GrowthBook chicago_config:
  raw={"appScopedEnabled":true,"batchOnly":true,"clipboardPasteMultiline":true,"coordinateMode":"pixels",
       "dispatchCuGrantTtlMs":1800000,"enabled":true,"hideBeforeAction":true,"mouseAnimation":true,
       "nativeMouseVariant":true,"pixelValidation":false,"screenshotFilter":true,"watchRecordEnabled":true}
  → enabled=true subGates={…} coordMode=pixels dispatchTtlMs=1800000 appScoped=false

The remote config is serving appScopedEnabled: true; the resolved value is appScoped=false. Nothing else in the gate can produce that pair on a Pro/Max, GrowthBook-fresh, macOS ≥ 15 machine except the version ceiling. For comparison, boots on 2026-08-28 (pre-launch) show the raw payload with no appScopedEnabled key at all and the same appScoped=false, so the server-side rollout has happened and this machine is being excluded purely by OS major.

Why this is worth a fix rather than a wait

• The cap is remote-configurable, so raising 1346958739 to 27 (or making the check >= the next unreleased major) needs no release.
• The docs promise "15 or later" with no maximum. Either raise the cap or document the ceiling so users on a beta know why the toggle does nothing.
• Failing silently is the worst of the three options: the toggle reads as on, the announcement says it's on, and the app behaves as if it's off.

Workaround

None. The version comes from process.getSystemVersion(), which cannot be overridden per-process, and the app is hardened-runtime signed so it can't be patched without breaking keychain access.