Debug recording (the DebugRecording per-stream setting → a debug-recordings/<did>/ dump) only worked on the in-process paths and the fd-4-pipe fallback, where main is in the data path and can tee. The zero-downtime detached MKV path and the WHIP worker put main OUT of the data path, so recording silently stopped there. Move the recording into the worker, uniformly across the isolated paths. main still owns the DECISION (shouldRecord needs the DB), evaluated once in buildWorkerConfig and passed as cfg.Record + cfg.DataDir in the handshake; the worker, which owns the data path, carries it out: - RunMKVIngestWorker tees its ingest media to dumpToFile when cfg.Record. - ServeWHIPIngestWorkerSocket passes cfg.Record to NewRecordingPeerConnection. - The now-redundant main-side tee is removed from MKVIngestIsolated, so there's one recording path (no double-record) and main stays out of the data path on the fd-4 path too. The in-process MKVIngest / NewPeerConnection recordings are unchanged. Bonus: because the worker owns the recording, a recording now survives a main restart along with the rest of the detached session. cfg.DataDir is only set when recording (rtcrec/dumpToFile panic on an empty DataDir, but they're only reached when enabled). Test: TestRunMKVIngestWorkerRecords runs the worker with Record + a temp DataDir and asserts debug-recordings/<did>/*.rtmp.mkv is written verbatim from the ingested media. Co-Authored-By: Claude Opus 4.8 <noreply@anthropic.com>