Cowork 'record a demonstration': mic control shown but narration silently dropped — WatchRecordVoiceover 'no api credentials configured' (coworkWatchRecord gate off while watchRecordEnabled on)

Bug report: Cowork "record a demonstration" — mic control shown, narration silently dropped ("no api credentials configured")

App: Claude desktop, v1.25927.0 (installed 2026-08-04), macOS 26.5.2 (Apple Silicon MacBook Air). Also reproduces identically in Cowork in a Chrome tab (claude.ai/cowork).

Revised 2026-08-05: this report was re-audited against raw command output. Findings are now split into what was directly observed on the machine versus the suspected mechanism, which could not be verified locally.

Symptom

Every "record a demonstration" take arrives with screen keyframes and UI actions but no audio and no transcribed narration. The mic level meter works on the pre-recording screen; audio dies the instant recording starts. Reproduced on 12 consecutive takes, 2026-08-05 10:11–11:14 PDT.

Verified findings (each backed by raw command output on the machine)

1. The recorder aborts on missing credentials at every take. ~/Library/Logs/Claude/swift.log contains 13 occurrences of

``
[Dictation] [warn] WatchRecordVoiceover.start: no api credentials configured
`
between 10:11:45 and 11:14:28 across 12 takes — each take's WatchRecorder monitors installed line is paired with the warning in the same second. The recorder's success-path strings (WatchRecordVoiceover: recording started, WatchRecordVoiceover: STT session failed mid-recording, WatchRecordVoiceover.startRecording failed`) appear nowhere in the log's entire history — the recorder has never gotten past the credential check on this machine.

1. The credential interface. The Swift addon (app.asar.unpacked/node_modules/@ant/claude-swift/build/Release/swift_addon.node, source path packages/desktop/claude-swift/Sources/ClaudeSwift/WatchRecordVoiceover.swift per embedded strings) exposes setCredentials(baseURL: String, cookieHeader: String, organizationUuid: String); the warning above is its no-credentials abort path.

1. The mic is never opened during a take. macOS Core Audio attribution (/usr/bin/log show --predicate 'subsystem == "com.apple.coreaudio" AND eventMessage CONTAINS "update_running_state"') shows Claude held the mic only during the pre-recording preview and closed it within the same second recording began (e.g. 11:14 take: Claude(3204) input_running:true 11:14:22.928 → false 11:14:28.007; swift.log take start 11:14:28; no Claude mic session during the take itself). Consistent with all permission layers being green — nothing ever requests the device during recording.

1. Flag state. The renderer processes run with --desktop-features containing "coworkWatchRecord":{"status":"unavailable"} (no reason field), while the app log shows the recording feature's GrowthBook config as chicago_config: ... "watchRecordEnabled":true.

Suspected mechanism (plausible, NOT established — please confirm or correct)

The JS side appears never to call setCredentials, and the naming alignment (WatchRecorder / WatchRecordVoiceover / coworkWatchRecord / watchRecordEnabled) suggests the recording UI is enabled by watchRecordEnabled while narration credentials are gated on coworkWatchRecord — producing silent takes with a working mic control and no user-facing error. This could not be verified locally: the main-process JS appears bytecode-compiled, so the call site is not inspectable, and whether coworkWatchRecord: unavailable is a server-side per-account gate is inferred (unlike unsupported entries, unavailable entries carry no local reason), not observed.

Ruled out (verified, not assumed)

• macOS mic permission: granted (com.anthropic.claudefordesktop, TCC auth full; was even reset and re-granted 10:22 during troubleshooting — no change).
• Mic hardware: working (level meters register; other apps capture fine).
• Entitlements: com.apple.security.device.audio-input present on the main app and Claude Helper.app; signature valid, notarized.
• App conflict: ruled out — the recorder aborts before ever requesting the device.
• Reinstall/relaunch (4 app instances) and multiple sign-out/sign-in cycles: same failure.
• Multiple workspaces: account has a single organization.
• Not the closed issue #52524 (speech-recognition entitlement / Caps Lock dictation) — different code path, and that entitlement is irrelevant here.

Asks

1. Confirm whether narrated watch-record requires coworkWatchRecord, and whether it is off for this account; enable/repair if so.
2. If the gate is intentionally off: hide the mic control and show "narration unavailable" instead of recording silent takes.
3. Surface WatchRecordVoiceover.start: no api credentials configured as a user-visible error.

Account email: jasonvrabe@gmail.com. Full raw command output for every claim above is available on request.