Thanks for this, @jensenpat — this is a careful, well-documented piece of work, and the three-part diagnosis (mode default → MOX gate → no CW audio source) is exactly right. I traced the threading and gating end-to-end and it holds up. CI is green on all three platforms + CodeQL.

What I verified

• Thread safety of the record pump — onCwRecordPump, m_cwPumpActive, m_cwPumpElapsed, and m_cwRecordSidetoneScratch are touched only on the audio thread; setCwKeyDown reaches the generator through CwSidetoneGenerator's atomic setters; m_cwKeyedThisOver is a proper std::atomic. The QTimer is correctly created on the audio thread via the queued startCwRecordPump(). ✅
• process() is additive (out[2*i] += …), so zeroing the scratch with assign(n, 0.0f) before each render is correct, and stereo sizing (frames*2 floats / frames*2*sizeof(int16)) matches. ✅
• Emit ordering — on the activation tick you emit cwRecordingActiveChanged(true) then fall through to a ~0-frame render, so onMoxChanged(true) is queued ahead of the first PCM; on deactivation you emit false and return, so no PCM trails the gate close. Single queue preserves order into the recorder thread. ✅
• Gate ownership — m_radioTransmitting && m_cwKeyedThisOver && !isTxStreaming() correctly excludes voice/DAX/tune overs and another MultiFlex client's TX. ✅
• All eight RecordingMode fallbacks flipped consistently to "Client". ✅
• Null guards at the automation boundary (m_qsoRecorder, m_audioEngine->clientTxTestTone()) are present. ✅

Worth surfacing (non-blocking)

1. The RecordingMode default flip is a silent behavior change for existing users. The value is only persisted when someone toggles it in Radio Setup (RadioSetupDialog.cpp:2483/2491), so every upgrading user who never touched it goes from radio-side → client-side recording on first launch after this lands. That's defensible given the feature was effectively dead, but it's a real product decision the maintainers should make consciously — and it deserves a CHANGELOG entry (this PR doesn't touch CHANGELOG.md, which sibling PRs in this batch do). Client-side capture also silently requires MIC = PC for voice, per your own note — an upgrading SSB user could end up with quieter/empty phone recordings without knowing why.

2. Trivial: the record error string advertises (start|stop|status|path) but dir is also a valid action (AutomationServer.cpp:2742) — worth adding for discoverability.

3. Optional: the pump free-runs at 100 Hz for the app's entire lifetime. The body early-returns cheaply, so this is fine, but if you wanted you could only start it when recording is armed.

Nice touch wiring the recorder-only sidetone generator at a fixed level so CW records even when the audible monitor is off, and the wall-clock frame accounting for morse timing. Scope (automation record/testtone verbs + the two Python harnesses) reads as the verification rig for this feature rather than creep. Just the default-flip call-out for a maintainer before merge.

_{🤖 aethersdr-agent · cost: $4.3843 · model: claude-opus-4-8}

Automated high-effort review (8 finder angles + verify). The correctness cluster mostly traces to one design choice: a free-running, audio-thread, wall-clock CW pump routed through the voice onMoxChanged/m_transmitting path via a queued cross-thread signal, plus a second always-on sidetone generator. CwSidetoneGenerator already exposes setSampleTap() (the TX CW decoder, #2417, uses it) which delivers the envelope-shaped sidetone on every process() block — driving the recorder from that tap, with the CW path owning its own gate (not overloading voice MOX), would dissolve findings #3/#4/#7/#9 at the root.

Independently shippable blockers: the dual-MOX-source clobber (#1), the all-users RecordingMode default flip (#2), and the recordingFilePath() data race (#5).

One more (can't inline — feedTxAudio isn't in this diff): QsoRecorder::feedTxAudio takes m_writeMutex before the !m_recording/!m_transmitting fast-path. The CW pump now feeds it ~100×/s from the audio thread; if the GUI thread holds the mutex during stopRecording/finalize disk I/O, the audio thread blocks inside the real-time pump → xrun. Check the atomics before locking.

Also noted (minor): the pump is started (queued) ~300 lines before its signal connections are made (first over after a fast startup is dropped); doTestTone assumes a TX audio pump it doesn't start (silent empty segment); the inline float→int16 uses 32768.0f vs the codebase's 32767.0f (QsoRecorder::float32ToInt16); per-tick QByteArray alloc + redundant zero-fill on the audio thread; brace-on-control-flow style; AppSettings read on each MOX edge; the analyzer hardcodes 16-bit WAV with no empty-file guard.

Requesting changes per the inline comments. Blockers before merge: (#1) the CW path overloads the voice onMoxChanged/m_transmitting gate — two producers clobber one shared flag/idle-timer; (#2) the all-users RecordingMode default flip from "Radio" to "Client" is out of scope and changes behavior on upgrade for everyone; (#5) recordingFilePath() reads m_file without the write mutex (UAF vs finalize). The correctness cluster (#3/#4/#7/#9) largely dissolves by driving the recorder from the existing CwSidetoneGenerator::setSampleTap() and giving CW its own gate rather than a free-running wall-clock pump on the audio thread. Happy to re-review once those are addressed.

Re-review after the blockers were resolved/decided (prior changes-requested dismissed).

Disposition of the three blockers:

• #1 CW pump architecture — not a blocker per maintainer call; jensenpat's free-running pump + recorder-sidetone generator stays. The earlier high-effort pass verified its threading/gating end-to-end (audio-thread-only state, atomic latch, queued timer start, additive render, ownership-correct gate).
• #2 RecordingMode "Client" default — approved as-is. (Worth a CHANGELOG line at release-prep noting client-side capture is now the default and needs MIC=PC for voice.)
• #3 real-time feed lock hazard — fixed.

Transparency: two commits here are my own maintainer edits, not jensenpat's:

• 94339219 — recordingFilePath() now reads m_file under m_writeMutex (was a data race / UAF vs finalize); record verb error string lists dir.
• db3387fd — m_recording made std::atomic<bool> with a lock-free fast path on feedTxAudio/feedRxAudio, so the ~100 Hz CW pump can't block the real-time audio thread on the write mutex during finalize; post-lock re-check stays authoritative (behavior unchanged).

The core feature — capturing local CW/CWX sidetone into Client-Side recordings across SSB↔CW — is well-built and hardware-verified (FLEX-8400M), the 3-part diagnosis was correct, and the two audio taps verify against the tree.

Approving. Merge once build + check-windows finish green on db3387fd (macOS already passed). Thanks @jensenpat.