[BUG] Computer use permission card renders with only "Deny" — no Allow option (macOS desktop, Cowork)

same here using version "1.49585.0" on windows 11

same here, German UI, macOS, Pro/Max

Additional data point (macOS, German UI, Pro/Max, 1.49585.0): the Allow button is missing only in newly created chats and projects started today. In older chats that existed before the regression, the approval card still renders "Allow for this session" and granting works. This is the opposite of what #93000 reports on Windows (old session broken, new session works), so the state seems to be tied to how the session was initialised rather than to session age. Accessibility and Screen Recording granted, app and macOS restarted, no change.

Confirming this on Windows, so it isn't macOS-specific or a localization issue.

Environment: Claude Desktop for Windows 1.49585.0, Electron 44.2.0, Node 24.20.0, win32 x64. Cowork cloud session linked to the local machine. Observed 2026-09-09.

Same symptom: the computer-use approval card renders its header, device name, app rows with tier badges, the "Your other windows will be hidden, then restored when Claude is done" notice, and a single Deny button with its Ctrl . hint. No approve control is painted anywhere, and the card is not clipped — there is whitespace to the right of and below Deny. computer_resolve_access returns valid entries; computer_request_access comes back User rejected every time; computer_list_granted_applications stays empty.

New detail — the control mounts but does not paint. The approve control is present in the focus order. Tabbing through the card places a visible focus ring on blank space where nothing is drawn. Pressing Space on that ring does nothing; pressing Enter does nothing. So the element exists in the tree, takes focus, renders zero pixels, and does not activate. That points at a render/layout failure rather than logic correctly hiding an unavailable action.

Corroborating: in a request that included Cursor, that row's app icon also failed to render — a blank gray placeholder square where the icon belongs. Two separate visual elements failing to paint within the same card.

Ruled out on my side:

| Hypothesis | Test | Result |
|---|---|---|
| Restricted/sentinel app is the trigger | Requested Notepad alone (tier: full, isSentinel: false) instead of Cursor (tier: click, isSentinel: true) | Still Deny-only |
| Malformed willHide — mine contained duplicate bundleIds (ScreenSketch ×3, PowerShell ×2, WindowsTerminal ×2) | Minimal request: apps + reason only, omitting willHide and screenshotFiltering | Still Deny-only |
| Duplicate entries generally | Retested when willHide returned only 2 clean entries | Still Deny-only |
| Computer use not enabled | Enabled it via the no-apps prompt — that prompt's affirmative control rendered and worked | Still Deny-only |
| Account or organization policy | Folder-access consent prompts approved successfully, twice, same session | Not policy |
| Stale renderer / pending update | Version constant at 1.49585.0 across a bridge reconnect; no pending update | Not an update |
| Transient runtime state | Full OS reboot | Still Deny-only |

Working correctly in the same app and session: the "turn on computer use" prompt (no-apps variant) and the folder-access consent prompt both rendered working affirmative controls — folder access was approved twice and granted. Two of three consent surfaces in the same build and session are fine. Only the computer-use app-grant card is affected.

Possible server-side origin. The original report notes the button disappeared mid-session on an unchanged build, having worked earlier the same morning. My Windows occurrence is the same calendar day. Two platforms, two builds, one day, and a reinstall/reboot fixing neither — that reads server-side rather than client-side.

Impact: computer use is completely unusable. No workaround found via mouse, keyboard, restart, or full reboot.

Same bug on Windows — worth noting, since this and #93135 are both labelled macOS and the troubleshooting so far has focused on TCC / Accessibility / Screen Recording. None of that applies here, so the cause isn't macOS-specific.

Reproduced on two Windows 11 machines, on two different app versions:

• Machine A — desktop app 1.49585.0, Electron 44.2.0, Node 24.20.0, Win 11 x64
• Machine B — desktop app 1.46388.2, Win 11

Roughly 3,000 builds apart, failing identically. Combined with #93135 being on 1.49585.0 on macOS, that's the same failure across two platforms and multiple client versions — which argues for a server-side change rather than a client regression.

Plan: Max, personal account, not under a business/Team org. (#93060 is on Anthropic API, #93135 on Max 20 — so it isn't entitlement-shaped either.)

One diagnostic I haven't seen in either thread: pressing Tab with the card focused moves focus out of the dialog entirely. So the Allow control isn't an unpainted or mis-styled button — it's absent from the focus order. Enter and Ctrl+Enter do nothing. (Deny advertises a Ctrl . shortcut; its counterpart has none.)

A second permission dialog in the same session works fine: device_request_folder_access prompted normally and granted C:\Users\<user>\Documents and C:\Users\<user>\Downloads without issue, minutes after a Notepad computer_request_access rendered Deny-only. So it isn't the permission layer broadly — it's specifically the computer-use approval card.

Also matching #93060: computer_resolve_access returns correct identities and live running-process data, and the Claude in Chrome connector connects, navigates and reads pages normally. Bridge is healthy.

Tested with Notepad (isSentinel: false, tier full) to rule out any system-level-app special casing — fails the same as Settings did.

Also ruled out on this account: fresh Cowork conversations, full logout and re-login, and no apps in the denied list.

This was working a few days earlier on the same account.

Suggest broadening the platform label — it isn't macOS-only.