CID Error
Plays a custom sound whenever a syntax, compile-time, runtime, or logical error occurs in your code.
Features
- Diagnostics detection — reacts to VS Code's own error squiggles, with dedup so an unfixed error doesn't replay the sound on every keystroke.
- Terminal / debug detection — reacts to command output in:
- Ordinary integrated terminals, via VS Code's Shell Integration API (requires shell integration to be active — on by default for bash/zsh/pwsh/fish in recent VS Code).
- Debug sessions (F5 / Run and Debug), via the Debug Adapter Tracker API.
- The bundled
CID Error: Run & Watch command, which runs the active file directly for interpreted languages (Python, Node, TypeScript via ts-node, Ruby, PHP, Lua).
- Regex-based error classification covering Python, JavaScript/TypeScript, Java, Kotlin, C/C++, C#, Rust, Go, PHP, Ruby, Dart, Swift, Lua, Node/npm/pnpm/yarn/Bun/Deno, Gradle, Maven, Cargo, GCC, Clang.
- Configurable cooldown, volume, custom sound files per error kind, per-language filtering, and independent toggles for diagnostics vs. terminal detection.
- Cross-platform sound playback (macOS
afplay, Windows PowerShell MediaPlayer, Linux paplay → ffplay → mpg123 → cvlc → aplay fallback chain).
Commands
| Command |
Description |
CID Error: Toggle Sound Alerts |
Enable/disable all sounds. |
CID Error: Test All Sounds |
Plays each sound kind once, bypassing cooldown. |
CID Error: Report Logical Error (manual) |
Manually trigger the "logical error" sound — these can't be auto-detected. |
CID Error: Run & Watch (with sound) |
Runs the active file and watches its stdout/stderr for errors. Requires a trusted workspace. |
Settings
| Setting |
Default |
Description |
cidError.enabled |
true |
Master on/off switch. |
cidError.watchDiagnostics |
true |
Detect errors from VS Code diagnostics. |
cidError.watchTerminal |
true |
Detect errors from terminal/debug-console output. |
cidError.ignoreWarnings |
true |
Only diagnostic errors trigger sounds. |
cidError.ignoreHints |
true |
Hints/info diagnostics never trigger sounds. |
cidError.cooldownMs |
1500 |
Minimum time between two sounds, per error kind. |
cidError.startupGraceMs |
4000 |
Ignore diagnostic sounds for this long after activation. |
cidError.volume |
100 |
Playback volume, 0-100. |
cidError.soundPaths |
{} |
Override sound files per kind, e.g. { "syntax": "/path/to/sound.mp3" }. |
cidError.languageFilters |
[] |
Restrict diagnostic sounds to these language IDs. Empty = all. |
cidError.captureDebugConsole |
true |
Default new debug sessions to the internal console so their output can be scanned. Disable if this conflicts with a launch config that needs a real terminal (e.g. a program reading stdin). |
Known limitations (caused by the VS Code API, not by this extension)
- Raw terminal byte stream is unavailable.
onDidWriteTerminalData is a proposed API gated behind --enable-proposed-api; installed extensions cannot use it. The Shell Integration API (onDidStartTerminalShellExecution) is the closest stable alternative and is what this extension uses for plain-terminal detection — but it only works when the shell has shell integration enabled. A custom prompt, an unsupported shell, or a user who has explicitly disabled shell integration falls outside this extension's terminal detection (debug-session and Run & Watch coverage still work in that case).
Run & Watch only supports interpreted languages run as a single file (Python, Node, TypeScript via ts-node, Ruby, PHP, Lua). Compiled languages (C/C++/Rust/Go/Java/etc.) need a build step before running, which is a project-specific, multi-step process outside the scope of "run this one file."
- Workspace Trust:
Run & Watch executes the active file as code and is blocked in untrusted workspaces. Diagnostics-based and terminal-output-based detection still work regardless of trust state.
- Remote environments (SSH/WSL/Dev Containers/Codespaces): sounds are played on whichever host the extension host process runs on. In most remote setups that's the remote machine, which typically has no audio output device — the extension logs this but can't work around it, since audio playback has to happen on a machine with real speakers.
Development / Testing
Unit tests cover error-pattern classification, diagnostic-fingerprint dedup logic, and cooldown behavior — all pure logic extracted from the VS Code-dependent modules so they run without a VS Code test harness:
npm test
Full integration testing against a real VS Code instance (diagnostics API, debug adapter tracker, shell integration) would use @vscode/test-electron and is recommended as a follow-up for a v1.0.0 release.
| |