Skip to content

Security: CipherArrow/claude-smart-check

SECURITY.md

Security Policy

This tool watches tmux panes and types into them. That makes its security boundaries worth stating precisely. The full design-level security model is in SMART-CHECK.md § Security; this file is about reporting.

Supported versions

Only the latest release on master is supported. There is no backporting.

The user's brake

Because this tool types into a terminal, it ships with an out-of-band stop that does not depend on the automation behaving correctly:

claude-auto-retry install-hotkey --key F9 --resume-key F10   # once

Pressing the key writes a pause file, and every send is gated by a synchronous check of that file performed immediately before the tmux send-keys call — in a wrapper around the send functions themselves, so no code path (present or future) can forget it. The binding lives in tmux's root table, so the key is consumed before Claude Code sees it and works even mid-turn. claude-auto-retry pause --all stops every session at once.

If you are auditing this project, that gate (src/pause.js + the wrapper in startMonitor) is the control worth attacking first: a way to make a keystroke reach a paused pane is a valid vulnerability report.

What counts as a vulnerability here

Please report anything that breaks the tool's stated guarantees, especially:

  • Injection-target escape — any way the monitor can be made to type into something other than the Claude Code TUI (a shell, another app), i.e. a bypass of the foreground-process gate.
  • Pause bypass — any keystroke reaching a pane whose pause file exists.
  • Destructive UI driving — any way the arrow-key/Enter picker logic can confirm a selector other than a model/effort dialog. The double-Escape history-rewind UI is explicitly deny-listed (smartCheck.pickerDenyPatterns) because confirming a row there would rewind the user's conversation; a way around that deny-list is a real finding.
  • Attacker-controlled keystrokes — any way pane content, state files, or config parsing can cause the monitor to type text an attacker chose, rather than the user's own fixed config strings / Escape / arrow keys.
  • Network activity — the tool claims zero network access; any code path that opens a socket is a bug of the highest severity.
  • Cross-user impact — any way one user's monitor/state can affect another user's session (state files are meant to be same-user only).
  • Install-time surprises — the install steps modifying anything beyond the documented files (~/.bashrc/~/.zshrc marker block, the StopFailure hook entry in ~/.claude/settings.json, systemd --user units, ~/.claude-auto-retry/).

Known, accepted limitations (not vulnerabilities)

  • Trigger spoofing: pane text is untrusted; content that displays a fake downgrade or rate-limit banner can trigger the predefined action sequences (interrupt, model switch, nudge, halt). The blast radius is limited to those fixed actions inside the Claude TUI. This is inherent to screen-scraping and documented; mitigations that tighten matching are welcome as hardening PRs.
  • Same-user local processes can write the control markers, pause files or config — there is no privilege boundary between a user and their own automation. Protecting against an attacker who already runs code as your user is out of scope.
  • A hotkey binding is global to its tmux server. bind -n consumes the key in every pane, Claude or not; that is inherent to intercepting a key before the application sees it. Bare printable keys are refused for this reason (a binding on p would make p untypable), and --force is documented as a footgun rather than treated as a bug.
  • capture-hotkey puts the terminal in raw mode while reading one keypress. It requires a TTY, restores the terminal on exit, and reads nothing but the key you press.
  • The nudge/rephrase messages are ordinary prompts and consume the user's plan.

How to report

Use GitHub's private vulnerability reporting on this repository (Security tab → "Report a vulnerability"). Please include the Claude Code version, tmux version, and a pane capture or transcript demonstrating the issue. Do not open a public issue for anything exploitable before a fix lands.

Best-effort response by a solo maintainer; fixes for confirmed boundary breaks (injection-target escape, attacker-controlled keystrokes, network activity) take priority over everything else in the project.

There aren't any published security advisories