[BUG] [Cowork] "Record a skill": trajectory built and consumed by renderer, but the task session receives no demonstration — no proposal generated, capture never persisted to disk

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?

A 447-second "Record a skill" capture completed successfully, but the resulting task session never received the demonstration and no proposal card was ever generated. The app did not crash and capture did not fail — the payload was dropped between the renderer and the task session.

Compounding this: the extracted images were never written to disk at any point, so there is no artifact to recover even with the app still running as the same process.

What happened (all times local, MDT / UTC-6, on 2026-08-21)

• 15:32:43 — [watch-record] start blocked — missing macOS TCC permission { missing: 'screen_recording' }
• 15:32:52 — app quits (expected after granting the TCC permission)
• 15:32:56 — app relaunches, [watch-record] controller initialized
• 15:33:11 — recording starts (session=new, mode=trajectory)
• 15:40:23 — Cowork session container provisioned (verified from inside the session: /home/claude created 2026-08-21 21:40:23 UTC)
• 15:40:38 — recording ends, 447.1s after start
• 15:40:43 — trajectory built: 446 frames → 22 images, 152 items, 177 blocks
• 15:40:43 — held for renderer, then held recording consumed (22 images, myAccessPlatformBlocked=false)
• 15:40:48 — renderer dismissed pill (epoch=2)
• ~15:45 — user asks the task whether the recording arrived; the session has no knowledge of any recording

The session received nothing

Inside the provisioned session: no uploads directory, no images in context, no demonstration content of any kind. The session could not produce a proposal because it never received the demonstration it was created to review.

The UI renders a "Recorded demonstration (447.1s)" step, but it is not expandable and exposes no screenshots — contrary to the documented behaviour in https://support.claude.com/en/articles/12512198-how-to-create-custom-skills

The capture was never persisted

A time-window search of the entire application-support tree between 15:33 and 15:45 (excluding node_modules and HTTP caches) returned 10 files, all infrastructure: VM disk image, vmIP, .cowork-adopted, .sdk-version, SharedStorage-wal, and Local Storage leveldb logs for preview partitions. No IndexedDB writes, no blob_storage writes, nothing image-sized. The claude.ai IndexedDB blob buckets are empty directories dated March–July.

This is arguably the more serious half of the report: even with the failure point fully diagnosed and the capturing process still alive, there was no artifact on disk to recover.

Ruled out

• Exceeded the ~10 minute cap — no; 447.1s is about 7m27s
• Crash during processing — no; no onQuitCleanup after 15:32:52, and main.log is continuous through 16:01+
• Unhandled rejection / native crash — no; grep for unhandled|fatal|SIGKILL|uncaught returns only stale RemotePluginManager timeouts from Aug 18–19, and Crashpad is untouched since Mar 13
• TCC denial — no; blocked at 15:32:43, granted, relaunched, and recording then ran normally
• User dismissed the proposal — no proposal was ever presented

Relationship to #84351

#84351 reports the app terminating at record start on a blocked media permission with empty requestingOrigin. This is a different failure at a different stage. Notably, this machine logged ~13 Blocked permission check warnings at 15:32:57–15:33:10 and did not terminate — recording began 1 second later. Those warnings appear to be non-fatal in 1.34493.1.

Unknown

Client-side logs cannot distinguish whether the payload was uploaded to the server and dropped there, or never left the client. claude.ai-web.log was actively written until 15:48 but contains zero references to watch-record, demonstration, trajectory, or the image count.

What Should Happen?

The 22 images and the trajectory should reach the task session, which reviews them and presents a proposal card to Save or Dismiss.

Additionally:

1. Persist the trajectory before handoff. Write the images and trajectory to durable storage keyed by session id, and delete only after the proposal is saved or dismissed. This alone converts this class of failure from unrecoverable data loss into a retry.
2. Acknowledge the handoff. held recording consumed should reflect confirmed receipt by the session, not dispatch from the main process.
3. Surface a timeout. A session holding a "Recorded demonstration" step that produces no proposal within a reasonable window should show an error and a retry affordance instead of hanging silently.
4. Make the demonstration step expandable, or don't render it. A step that claims retained screenshots but exposes none is actively misleading during diagnosis.
5. Log the renderer side. claude.ai-web.log had no record of a 22-image trajectory handoff, which made the boundary impossible to inspect from the client.

Error Messages/Logs

~/Library/Logs/Claude/main.log — times are local (MDT, UTC-6)

2026-08-21 15:32:43 [warn] [watch-record] start blocked — missing macOS TCC permission { missing: 'screen_recording' }
2026-08-21 15:32:52 [info] Running onQuitCleanup: sim-recordings
2026-08-21 15:32:56 [info] [watch-record] controller initialized
2026-08-21 15:32:57 [warn] Blocked permission check {          (x13 through 15:33:10, non-fatal)
2026-08-21 15:33:11 [info] [watch-record] pill shown
2026-08-21 15:33:11 [info] [watch-record] recording started (session=new, mode=trajectory)
2026-08-21 15:36:11 [info] [watch-record] frame buffer halved → 360 frames, interval now 500ms
2026-08-21 15:39:12 [info] [watch-record] frame buffer halved → 360 frames, interval now 1000ms
2026-08-21 15:40:43 [info] [watch-record] trajectory built: 446 frames → 22 images, 152 items, 177 blocks
2026-08-21 15:40:43 [info] [watch-record] held for renderer (mode=trajectory, 22 images, session=new)
2026-08-21 15:40:43 [info] [watch-record] held recording consumed (22 images, myAccessPlatformBlocked=false)
2026-08-21 15:40:48 [info] [watch-record] renderer dismissed pill (epoch=2)

The renderer logged nothing about the handoff:

$ grep -inE "watch-record|demonstration|trajectory|22 images" ~/Library/Logs/Claude/claude.ai-web.log
(no matches — file was actively written until 15:48)

Nothing was persisted during the handoff window:

$ find ~/Library/Application\ Support/Claude -newermt '2026-08-21 15:33:00' \! -newermt '2026-08-21 15:45:00' \
    -type f \! -path '*/node_modules/*' \! -path '*/Cache/*' \! -path '*/Code Cache/*'
vm_bundles/claudevm.bundle/sessiondata.img
vm_bundles/claudevm.bundle/vmIP
vm_bundles/claudevm.bundle/.cowork-adopted
SharedStorage-wal
claude-code-vm/.sdk-version
Partitions/launch-preview-static/Network Persistent State
Partitions/launch-preview-static/Local Storage/leveldb/000003.log
Partitions/cowork-file-preview/SharedStorage-wal
Partitions/cowork-file-preview/Network Persistent State
Partitions/cowork-file-preview/Local Storage/leveldb/000003.log

No IndexedDB writes, no blob_storage writes, nothing image-sized.

No crash artifact was produced: ~/Library/Application Support/Claude/Crashpad is untouched since Mar 13,
and sentry/queue has not changed since May 10.

(Log excerpts redacted of org IDs, device UUIDs, bridge URLs, and OAuth cache keys.)

Steps to Reproduce

Observed once (n=1). No deliberate reproduction was attempted, since each attempt costs a full recording with no expectation of a different result. The exact sequence that produced it:

1. In the Claude desktop app on macOS, open the + menu and choose Record a skill.
2. Recording is blocked by macOS for a missing Screen Recording TCC permission. Grant it; the app quits and relaunches (expected macOS behaviour for that permission).
3. About 15 seconds after the relaunch, start the recording again. It starts normally.
4. Perform a workflow for roughly 7.5 minutes, narrating as you go, then stop.
5. The trajectory builds successfully (446 frames → 22 images) and is logged as held recording consumed by the renderer.
6. The task displays a "Recorded demonstration (447.1s)" step and then never produces a proposal card. Waiting does not help; the step is not expandable; no error is shown anywhere.

Possibly relevant, but speculation not supported by direct log evidence: the app had relaunched about 15 seconds before recording started, as part of granting the Screen Recording permission. A session or renderer binding established across that relaunch may have been stale.

Claude Model

None

Is this a regression?

I don't know

Last Working Version

_No response_

Claude Code Version

Claude Desktop 1.34493.1 (bundled claude-code 2.1.237), Electron 42.9.2, Node 24.18.1

Platform

Anthropic API

Operating System

macOS

Terminal/Shell

Terminal.app (macOS)

Additional Information

Environment

• macOS 26.6.1 (build 25G76), Apple Silicon (MacBook Air)
• Claude Desktop 1.34493.1 / Electron 42.9.2 / Node 24.18.1
• Bundled claude-code 2.1.237 (installed 2026-08-20 22:41)
• Timezone MDT (UTC-6)
• Screen Recording and Accessibility TCC permissions both granted

Impact

• 7.5 minutes of user work destroyed with no error surfaced anywhere in the UI.
• No signal that anything went wrong — the task simply never produces a proposal, and the demonstration step looks superficially normal.
• No recovery possible even in principle, because nothing is written to disk.
• Roughly 30 minutes of log forensics were required to establish that the recording was unrecoverable rather than merely missing.

Secondary observation: capture fidelity degrades mid-recording

15:36:11  frame buffer halved → 360 frames, interval now 500ms
15:39:12  frame buffer halved → 360 frames, interval now 1000ms

A recording well within the documented ~10 minute limit halved its sampling rate twice, so the final third was captured at a quarter of the initial fidelity, and 447 seconds distilled to just 22 images. If longer recordings systematically produce lower-quality skills, that tradeoff should be surfaced in the UI — users have no way to know their later steps are being sampled more coarsely than their earlier ones.