Summary

When the persisted settings store (~/.screenpipe/store.bin) has disable_audio: true baked in, passing --audio-device "<name>" on the command line is silently ignored. The CLI flags appear to take effect (boot succeeds, /audio/device/start API returns {"success": true}, last_audio_timestamp even advances briefly), but the boot config table prints:

│ audio disabled         │ true                               │
│ audio devices          │                                    │
│                        │ disabled                           │

…and no audio_chunks rows are ever written. There is no --enable-audio (or equivalent) flag to override the persisted disable_audio: true from the command line.

Root cause (in source)

crates/screenpipe-engine/src/cli/mod.rs — RecordArgs::into_recording_config:

let persisted_settings = load_recording_settings_from_store(&data_dir)?;
let loaded_from_store = persisted_settings.is_some();
let mut settings = persisted_settings.unwrap_or_else(|| self.to_recording_settings());
if loaded_from_store {
    self.apply_explicit_overrides(&mut settings, sources);
}

…and apply_explicit_overrides:

if sources.disable_audio {
    settings.disable_audio = self.disable_audio;
}
if sources.audio_device {
    settings.audio_devices = self.audio_device.clone();
    settings.use_system_default_audio = false;
}

sources.disable_audio is true only when --disable-audio is explicitly on argv (value_source() == Some(ValueSource::CommandLine)). Passing --audio-device "..." sets sources.audio_device = true but does not touch settings.disable_audio. Result: if the store has disable_audio: true, the audio device list is updated but audio recording stays disabled.

Reproduction

1. Run screenpipe record --audio-device "MacBook Pro Microphone (input)" — audio captures normally; daemon writes disable_audio: false to ~/.screenpipe/store.bin.
2. Something flips disable_audio: true in the store (UI toggle, API call, etc.).
3. Restart screenpipe record --audio-device "MacBook Pro Microphone (input)" (same command, audio device flag still present).
4. Observe: boot table reads audio disabled: true, no audio_chunks rows accumulate, but /audio/device/start still returns {"success": true} and last_audio_timestamp advances briefly per /health.
5. Deleting ~/.screenpipe/store.bin and restarting fixes it (the daemon regenerates the store from CLI args).

Real-world impact

Caught this after 9 days of silent audio outage on 0.3.345 → 0.3.349. Video kept capturing, /health looked happy enough that an external monitor would miss it, and the dedicated audio-validation cron we wrote logged ok: false daily but the alert path wasn't surfaced loudly to the user. The boot config table was the only place the truth was visible.

Suggested fix

In apply_explicit_overrides, treat any explicit audio-input flag as a signal that the user wants audio on. Either:

• Option A — --audio-device and/or --use-system-default-audio imply disable_audio = false:

  if sources.audio_device || sources.use_system_default_audio {
      settings.disable_audio = false;
      if sources.audio_device {
          settings.audio_devices = self.audio_device.clone();
          settings.use_system_default_audio = false;
      }
      if sources.use_system_default_audio {
          settings.use_system_default_audio = self.use_system_default_audio;
      }
  }

• Option B — Add an explicit --enable-audio flag that mirrors --disable-audio in reverse, so users can flip the persisted state from the command line without deleting the store.

Option A matches user intent on every CLI invocation I can imagine and avoids new flags. Option B is more explicit but requires users to know the flag exists.

Either way, the boot config table should arguably warn-log when --audio-device is passed but settings.disable_audio remains true — that's the smoking gun and right now it's only visible if you read the config table carefully.

Workaround until fixed

rm ~/.screenpipe/store.bin and restart the daemon. The store regenerates from CLI args with the correct disable_audio: false. Confirmed on 0.3.349 (and presumably any version with the current apply_explicit_overrides shape).

Environment

• screenpipe 0.3.349 (also affected on 0.3.345)
• macOS Darwin 25.4.0 (Apple Silicon)
• Launched via custom LaunchAgent wrapping the npm-installed CLI