Instant mode "start recording" button doing nothing

[julianwitzel]

Description

In Cap Desktop, when "Instant Mode" is selected, the "Start Recording" button appears active and clickable but does nothing on click — no recording starts, no UI feedback, and notably no log output anywhere.

Studio Mode works correctly on the same setup; the issue is specific to Instant Mode.

Reproduction

1. Self-host Cap (this issue may also affect Cap Cloud, untested)
2. Connect Cap Desktop to the self-hosted instance, sign in successfully
3. Open Cap Desktop, select "Instant Mode" in the recording mode dropdown
4. Confirm display, camera, and microphone are selected (all show "On")
5. Click "Start Recording"

Expected: Recording starts (live-streaming segments to the server).
Actual: Nothing happens. Button click has no visible effect.

Logs

The most surprising part: no logs are produced anywhere when the button is clicked.

• ~/Library/Logs/so.cap.desktop/cap-desktop.log.YYYY-MM-DD — completely silent during the click
• docker logs cap-web (server side) — no incoming requests
• docker logs cap-media-server — only the periodic /health checks, nothing else
• macOS Console.app filtered to "Cap" / "so.cap" — also silent

This suggests the click handler isn't even firing, or it's failing in a code path that doesn't include any logging.

Environment

• Cap Desktop version: 0.4.84
• macOS: Tahoe 26.x, Apple M4 (MacBook Pro 16")
• Display: Built-in Retina, 3456x2234 @ 120FPS (cannot be downscaled in the recording target picker)
• Server: self-hosted, ghcr.io/capsoftware/cap-web:latest (current as of 2026-04-28)
• Authentication: signed in via Google OAuth, session valid (Studio Mode recordings + uploads work fine on the same session)
• Cap Server URL in Desktop settings: correct, pointing to self-hosted instance

What works

• Studio Mode recording → upload → playback all functional
• Authentication, organization, sharing pages all work
• Cap Desktop is otherwise fully responsive (settings open, window controls work, dropdowns work)

What I tried

• Restarting Cap Desktop — no change
• Toggling camera/microphone off and on — no change
• Switching to Studio Mode and back — no change
• Watching all log sources simultaneously while clicking — confirmed: no log output anywhere

Possibly Related

The Cap server has the known [local world] Workflow SDK bugs documented in #1550, #1539, #1651, with PR #1630 attempting a bypass. Since Instant Mode appears to depend on server-side workflow segments (source.type === "desktopSegments" in the share page code), this might be the same root cause manifesting differently — i.e. the Desktop client tries to set up a server-side workflow before recording starts, fails silently, and the button never proceeds.

If that's the case, this issue may resolve once #1630 (or an upstream fix to the Vercel Workflow SDK) lands. But the silent failure with zero logs is itself a UX bug worth tracking — even if the underlying workflow issue is

[linear]

CAP-695

[tembo]

I found the root cause of why the button does nothing with no logs. In apps/desktop/src/routes/target-select-overlay.tsx:1754, the commands.startRecording() call fires the IPC command but doesn't handle the returned Promise:

commands.startRecording({
    capture_target: props.target,
    mode: rawOptions.mode,
    capture_system_audio: rawOptions.captureSystemAudio,
});

For Instant Mode, the Rust backend at apps/desktop/src-tauri/src/recording.rs:707-729 makes an HTTP call to create_or_get_video_with_mode() which hits your self-hosted server's /api/desktop/video/create?recordingMode=desktopSegments endpoint. If this call fails (auth issues, server errors, or the workflow SDK bugs from #1550), the backend returns RecordingAction::InvalidAuthentication or throws an error - but the frontend silently drops it because the Promise isn't awaited or handled.

The fix is to wrap the call with the existing handleRecordingResult() utility from apps/desktop/src/utils/recording.ts, which shows an error dialog for InvalidAuthentication and UpgradeRequired responses. This pattern is already used elsewhere in the codebase (e.g., line 409 in in-progress-recording.tsx).

Since you mentioned the server shows no incoming requests when clicking, the most likely scenario is the desktop app's HTTP request to your self-hosted Cap server is failing before reaching the server (SSL/DNS/network issue between the app and your server URL). Check that the "Cap Server URL" in desktop Settings matches your self-hosted instance's URL exactly, and that the desktop app can reach it (no firewall/proxy issues).

As for the related workflow SDK issues (#1550, #1539), those affect post-upload processing (transcription, AI generation) rather than the initial video creation call - so they shouldn't prevent recording from starting. PR #1630 was closed without merging.

[julianwitzel]

Update with diagnostics from a debugging session:

Confirmed via tcpdump: Cap Desktop sends multiple TCP packets to the server when "Start Recording" is clicked in Instant Mode (TLS handshake + 3 separate request payloads over ~14 seconds).

Confirmed via server logs: the only requests reaching cap-web are auth/user-fetch calls (Bearer <token> polling). The /api/desktop/video/create endpoint is never invoked.

Confirmed via DB watch: no new row in the videos table is created when clicking Start Recording in Instant Mode. Studio Mode on the same setup correctly creates a row with source: {"type": "desktopMP4"} and proceeds normally.

Verified not the cause:

• Auth: API key valid, user fetched correctly with stripeSubscriptionStatus: 'active'
• Server reachable: /api/auth/session returns 200, /api/desktop/video/create?recordingMode=desktopSegments returns 401 without auth as expected
• userIsPro() returns true on self-hosted regardless of subscription state (per packages/utils/src/constants/plans.ts)
• Cap Server URL configured correctly in Desktop settings (https://cap.zingstack.com)

Conclusion: The desktop client appears to bail out of the Instant Mode flow client-side, before issuing the create video request. The Network packets observed are auth polls, not the recording-creation call. The bot's hypothesis about the commands.startRecording() Promise being unhandled (#1735) seems consistent with this — but the underlying cause of the early bailout in Rust/Tauri layer is not visible without devtools or app-level logs (none of which appear to exist for this code path).

Reproduces 100%. Studio Mode unaffected.