Preventing Mass-Staging: OpenHands and git add -A

Correction note (2026-10-13). The per-call timings and latency figures that appeared in this article had no benchmark behind them and were removed. Sample output in this article is illustrative, not a recorded run. The only published measurement is p50 0.39 ms and p99 1.91 ms (sigmashake-bench daemon-socket run, 2026-06-10, ssg 0.29.156, n=500). Sub-2 ms evaluation is a design target.

Correction note (2026-10-13). An earlier version of the rules in this article used ==, which the rule DSL does not have, so the rules did not load. The rules now use EQUALS.

Describe the task

You ask OpenHands to commit the changes it just made. The agent decides to stage everything at once:

git add -A

Without a properly configured .gitignore, this stages .env files, local database dumps, compiled binaries, and any credentials that have landed on disk during the session. SSG's no-git-add-all rule blocks the operation before the index is modified.

# illustrative sample output
[BLOCK] bash › git add -A — rule: no-git-add-all

Give SSG context

SSG evaluates OpenHands's shell commands via the SSG MCP Server integration for OpenHands agents.

Required context

rule no-git-add-all {
  enabled true
  priority 80
  severity error
  DENY execution
  IF command EQUALS "git add -A"
  OR command EQUALS "git add ."
  OR command EQUALS "git add --all"
  MESSAGE "Mass-staging is blocked. Stage specific files or directories instead."
}

Optional context

Switch to ASK if you want to review mass-staging rather than block it outright:

rule confirm-git-add-all {
  enabled true
  priority 80
  severity warning
  ASK execution
  IF command EQUALS "git add -A"
  OR command EQUALS "git add ."
  PROMPT "About to stage all changes. Confirm after reviewing git status output?"
  MESSAGE "About to stage all changes. Confirm after reviewing git status output?"
}

What SSG does

SSG uses exact string matching (==) to catch the canonical forms of mass-staging. OpenHands receives the block with your message and can reformulate — staging specific files instead of the entire working tree.

Ask the agent to stage specific files

git add -A was blocked. Please run git status first, then stage only the source files
relevant to this change. Do not stage .env, *.log, or compiled artifacts.

The agent will typically respond with a targeted git add src/ or a list of specific file paths.

Pair with a .gitignore audit

Mass-staging is dangerous when .gitignore has gaps. Use SSG's write-call interception to also block attempts to remove .gitignore entries for sensitive paths:

rule protect-gitignore {
  enabled true
  priority 85
  severity error
  DENY write
  IF path ENDS_WITH ".gitignore"
  AND content NOT CONTAINS ".env"
  MESSAGE ".gitignore must always ignore .env files."
}

Audit staged content before each commit

Set up an ASK rule on git commit so a human reviews the staged diff before it's committed — a second line of defense after the add rule:

rule confirm-commit {
  enabled true
  priority 50
  severity info
  ASK execution
  IF command STARTS_WITH "git commit"
  PROMPT "About to commit. Have you reviewed the staged diff with git diff --cached?"
  MESSAGE "About to commit. Have you reviewed the staged diff with git diff --cached?"
}

How your rule handles command variations

Agents use variations: git add -A, git add ., git add --all. The == operator matches exactly — list all variants explicitly, or switch to CONTAINS "git add" with AND command NOT CONTAINS "src/" if you want a broader net.

Check the rule against your workflow

If your workflow legitimately uses git add . after wiping and regenerating files from scratch, switch to ASK mode so you can confirm the staging rather than blocking it outright.