[BUG] [Cowork] "Record a Skill" instantly terminates the macOS desktop app — internal `media` permission check blocked with empty requestingOrigin

Status Open
Reported on v2.1.221
Maintainer reply None cached
Activity 1 comment · opened Aug 6, 2026

Preflight Checklist

  • [x] I have searched existing issues and this hasn't been reported yet
  • [x] This is a single bug report (please file separate reports for different bugs)
  • [x] I am using the latest version of Claude Code

What's Wrong?

This is the Claude desktop app (Cowork) on macOS, not the CLI — filing here since Cowork desktop bugs are triaged in this repo. The form below is CLI-shaped; version/terminal fields are answered with desktop-app equivalents.

Clicking Record in Cowork terminates the entire app within ~2 seconds. Every Claude process exits. No macOS crash report is ever produced.

The final entry written to ~/Library/Logs/Claude/main.log before the process dies is Claude's own Electron permission handler denying its own media permission request, with every origin/URL field empty. media is the permission a getDisplayMedia screen-capture call requires.

macOS Screen Recording and Accessibility are both granted — verified directly against the system TCC database. The request is refused inside the app, before macOS is ever consulted:

com.anthropic.claudefordesktop | kTCCServiceAccessibility | 2
com.anthropic.claudefordesktop | kTCCServiceScreenCapture | 2

(from /Library/Application Support/com.apple.TCC/TCC.db; auth_value = 2 means allowed)

Likely cause: the capture request reaches the permission handler with an unpopulated frame context (requestingOrigin: '', requestingUrl: '', topFrameUrl: ''), an origin check fails closed and denies it, and the recorder then hits the rejected stream promise with no handler. Two details favour an unhandled rejection over a native crash: no .ips file is generated in either DiagnosticReports directory across weeks of reproductions, and no shutdown sequence is logged — the log simply stops mid-stream.

That the same batch also blocks web-app-installation and geolocation with identically empty fields suggests the whole permission-check batch is being evaluated against an uninitialised frame context.

Ruled out

  • macOS permissions — both granted, see TCC query above
  • Memory pressure — ~1.3 GB free at the moment of failure, no jetsam event anywhere near it, [process-memory] values normal immediately prior
  • Stale version — reproduces on 1.25927.0 (released the same day) and on 1.24012.9
  • Plugins/MCP — the only startup errors are an unrelated cockroachdb-toolbox MCP failure and a recurring credentials TypeError, both of which occur on every launch including sessions where recording is never invoked

Feature flags were healthy at crash time: watchRecordEnabled: true, and [watch-record] controller initialized logs cleanly at startup. The failure occurs only when recording is actually initiated.

What Should Happen?

The recorder acquires a screen-capture stream and recording begins.

Error Messages/Logs

Final lines written to ~/Library/Logs/Claude/main.log before termination.
Note the empty requestingOrigin / requestingUrl / topFrameUrl:

2026-08-05 20:31:51 [info] [PluginsFetcher] fetchPluginEnabledState: 26 overrides
2026-08-05 20:31:53 [warn] Blocked permission check {
  permission: 'media',
  requestingOrigin: '',
  requestingUrl: '',
  isMainFrame: true,
  topFrameUrl: ''
}
        ... 'media' blocked x4 total, then:
2026-08-05 20:31:53 [warn] Blocked permission check {
  permission: 'web-app-installation',
  requestingOrigin: '',
  requestingUrl: '',
  isMainFrame: true,
  topFrameUrl: ''
}
2026-08-05 20:31:53 [warn] Blocked permission check {
  permission: 'geolocation',
  requestingOrigin: '',
  requestingUrl: '',
  isMainFrame: true,
  topFrameUrl: ''
}

  <<< process dies here - no further output, no shutdown sequence >>>

2026-08-05 20:32:47 [info] Starting app {      <-- manual relaunch by user
  appVersion: '1.25927.0',
  isPackaged: true,
  platform: 'darwin',
  arch: 'arm64',
  nodeVersion: '24.18.0'
}

Steps to Reproduce

  1. Launch the Claude desktop app on macOS with Screen Recording and Accessibility already granted to Claude.
  2. Open Cowork.
  3. Click Record to begin recording a skill.
  4. The app terminates within ~2 seconds. The window disappears and all Claude processes exit. No crash dialog and no crash report.

Reproduces 100% of the time, across multiple app versions.

Claude Model

Not sure / Multiple models

Is this a regression?

No, this never worked

Last Working Version

_No response_

Claude Code Version

Claude desktop app 1.25927.0 (Cowork) - not the CLI

Platform

Anthropic API

Operating System

macOS

Terminal/Shell

Other

Additional Information

Environment

| | |
|---|---|
| Claude desktop | 1.25927.0 (also reproduces on 1.24012.9) |
| macOS | 26.4 (build 25E246) |
| Hardware | Mac mini, Apple Silicon (arm64), 16 GB RAM |
| Electron/Node | Node 24.18.0 |
| CCD | 2.1.221 |
| Plan | Max |

Possibly separate issue: on every launch, regardless of recording, the following repeats 8-10 times, followed by a Sentry caught event with type: 'Unknown', value: 'No message':

[error] Failed to configure API credentials: TypeError: Cannot read properties of undefined (reading 'serialize')
    at .../app.asar/.vite/build/index.chunk-DbtHrS9S.js:1:47554
    at Array.map (<anonymous>)
    at V (.../index.chunk-DbtHrS9S.js:1:47520)
    at async O (.../index.chunk-DbtHrS9S.js:1:44869)
    at async Object.D (.../index.chunk-DbtHrS9S.js:1:44355)

Happy to supply full logs, the complete TCC dump, or run further diagnostics on request.

View original on GitHub ↗

This issue has 1 comment on GitHub. Read the full discussion on GitHub ↗