fix(cli): explicit audio-input flags override persisted disable_audio#3804
Merged
louis030195 merged 1 commit intoJun 3, 2026
Merged
Conversation
When the persisted settings store has disable_audio: true, passing --audio-device on the command line was silently ignored: apply_explicit_overrides set audio_devices but never cleared disable_audio, so recording stayed off with no CLI way to re-enable it short of deleting store.bin. Reported in screenpipe#3648. Treat an explicit --audio-device or --use-system-default-audio as a signal that the user wants audio on, clearing a persisted disable_audio and logging a warning when it does. An explicit --disable-audio on the same invocation still wins, and absent flags leave the persisted value untouched. Adds unit tests for the three precedence cases.
louis030195
reviewed
Jun 3, 2026
louis030195
left a comment
Collaborator
There was a problem hiding this comment.
crates/screenpipe-engine/src/cli/mod.rs:1028 — @BohdanChuprynka does coreaudio system flag also override disable_audio?
generated by the screenpipe pr-review pipe (https://screenpi.pe), not written by a human — reply and tag @louis030195 if it got something wrong.
louis030195
pushed a commit
that referenced
this pull request
Jun 3, 2026
Vision-side mirror of #3804. An explicit --monitor-id / --use-all-monitors now clears a persisted disable_vision:true; otherwise the monitor is set but screen capture stays off — the same silent failure as the audio case in #3648. An explicit --disable-vision on the same command still wins (guarded), and a flag-less run leaves the persisted value untouched (use_all_monitors's true default is not counted as an explicit source). Adds 3 unit tests covering the precedence. Co-Authored-By: Claude Opus 4.8 <noreply@anthropic.com>
This file contains hidden or bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
2 participants
Add this suggestion to a batch that can be applied as a single commit.This suggestion is invalid because no changes were made to the code.Suggestions cannot be applied while the pull request is closed.Suggestions cannot be applied while viewing a subset of changes.Only one suggestion per line can be applied in a batch.Add this suggestion to a batch that can be applied as a single commit.Applying suggestions on deleted lines is not supported.You must change the existing code in this line in order to create a valid suggestion.Outdated suggestions cannot be applied.This suggestion has been applied or marked resolved.Suggestions cannot be applied from pending reviews.Suggestions cannot be applied on multi-line comments.Suggestions cannot be applied while the pull request is queued to merge.Suggestion cannot be applied right now. Please check back later.
Problem
When
~/.screenpipe/store.binhasdisable_audio: true, passing--audio-device "<name>"on the CLI is silently ignored. InRecordArgs::apply_explicit_overrides(crates/screenpipe-engine/src/cli/mod.rs), an explicit--audio-devicesetsaudio_devicesand clearsuse_system_default_audiobut never touchesdisable_audio, so the persisteddisable_audio: truewins and recording stays off. There is no CLI flag to flip it back; the only workaround is deletingstore.bin.Reported in #3648 (caught after about 9 days of silent audio outage: video kept recording and
/healthlooked fine, so it was easy to miss).Fix
Treat an explicit
--audio-deviceor--use-system-default-audioas a signal that the user wants audio on, so it clears a persisteddisable_audio: trueand logs a warning when it does. An explicit--disable-audioon the same invocation still wins (guarded), and when no audio flag is passed the persisted value is left untouched.Because
--audio-devicecounts as a recording override, the resolved settings (withdisable_audiocleared) are persisted back tostore.bin, the same as every other override flag, so a later run without flags keeps audio on.The report also proposed a separate
--enable-audioflag (Option B); treating the existing audio-input flags as the enable signal keeps the surface smaller and matches the reporter's stated preference.Testing
cargo test -p screenpipe-engine --lib. Added three unit tests covering the precedence:--audio-deviceover persisteddisable_audio: truere-enables audio and sets the device,--disable-audiostill wins when combined with--audio-device,disable_audio: trueunchanged.Closes #3648.