A coding assistant changes the two files you asked it to edit. The diff looks reasonable. Is the next Git operation safe to proceed?
Not necessarily. You might be in the wrong repository. An extra file might already be staged. The branch or configured push destination might have changed. Or the secret scanner might have failed to run at all.
These are not necessarily mistakes in the generated code. They are mismatches between the workflow you authorized and the Git state that actually exists.
I built a small, public reference Git Safety Harness to check selected mismatches before a later operation. It is a PowerShell-based, fail-closed workflow control—not a sandbox, not an independent enforcement boundary, and not a guarantee of safe AI-generated code.
Suppose the authorized work is:
docs/article.md and public/article.html in a particular repository.main. origin against an explicitly approved URL.
The harness does not invent these expectations. A human or an authorized workflow must define them first. The harness then compares selected observed Git state against them.
| Check | Question before proceeding | Example of a reason to stop |
|---|---|---|
| Repository Root | Is this the intended Git repository? | The command is running in another valid checkout. |
| Write Set | Are observed tracked changes and non-ignored untracked paths within the allowed set? | README.md changed even though it was not authorized. |
| Stage Set | Does the actual Git index contain only explicitly allowed staged paths? | An unrelated file was staged earlier. |
| Branch | Is the current symbolic branch the expected branch? | HEAD is detached or the branch differs. |
| Push URL | Does the selected remote have exactly one configured push URL, matching the approved URL? | origin points somewhere else, or has multiple push URLs. |
| Secret Scan | Can Gitleaks run and accept the staged diff? | Gitleaks is missing, cannot execute, or exits nonzero. |
Each question has a different failure mode. A PASS from one check does not substitute for the others.
The Write Set asks which paths are allowed to change. The Stage Set asks a different question: which paths are allowed in the Git index for the next operation?
The reference implementation reads the actual index with git diff --cached --no-renames --name-only and compares staged paths with a separate allow-list. That is a separate comparison from the Write Set, which covers staged and unstaged tracked changes as well as non-ignored untracked paths, using its own allow-list.
The approved Write Set contains both docs/article.md and public/article.html. The approved Stage Set contains only docs/article.md. Now imagine the following hypothetical output, not a captured test transcript:
$ git diff --cached --no-renames --name-only
docs/article.md
public/article.html
Both paths are allowed to change, so their presence alone does not violate the Write Set. But public/article.html is not allowed in the index for this operation. The reference implementation treats this as a Stage Set mismatch and reports GSH_STOP_STAGE_SET instead of accepting that staged state.
What would happen next? Consider two hypothetical paths from this same Git state:
git commit without changing the index, GSH_STOP_STAGE_SET and a nonzero result. The calling workflow stops This illustrates a workflow boundary, not a measured incident or a new test result. It also does not mean that the harness itself blocks direct Git commands: if an actor bypasses the checked path, the local Layer-2 harness cannot enforce that stop.
Likewise, checking a remote's fetch address is not enough to establish its push destination. The harness inspects push URLs and requires one exact match.
If a required state cannot be confirmed, the normal harness path stops rather than treating missing evidence as success.
That includes a repository root that cannot be resolved, an unexpected branch, an unavailable Gitleaks executable, and a scanner execution failure. The validated PowerShell wrapper also treats invocation errors, a missing child exit status, and nonzero exits as failures.
STOP is not an instruction for the assistant to silently repair the situation and continue. It is a point for inspecting the observed state and obtaining any necessary human decision.
The commit-pinned Validation Record reports results for the identified implementation in documented Windows reference environments:
The tests used synthetic local remotes and recorded bounded results for the identified implementation and environments. They did not establish universal compatibility, unbypassability, or the safety of a later real-world push or deployment.
The Evidence Pack from that later revalidation preserves execution output, case results, exit codes, and a SHA-256 manifest. These are records of the later run, not the original run’s raw logs.
Three limits matter especially in AI-assisted workflows:
git push. Its Gitleaks check covers the staged diff examined by the scanner, not every file or every secret.
Those limitations are reasons to keep human approval separate from independent enforcement, such as repository-side controls. Human approval is a workflow decision, not independent enforcement; the local harness replaces neither.
The goal is not to prove that an AI assistant is safe. It is narrower: before a selected Git workflow continues, make certain mismatches observable and stop when required checks cannot be accepted.
The full English design article on OSIIX explains the checks in detail. For the current implementation—including its separate AllowedStagedFiles parameter—use the commit-pinned source, Getting Started guide, and limitations, rather than treating every illustrative snippet in the earlier article as the latest tested code.
If you use AI-assisted Git automation, which of these checks is enforced outside the agent-controlled execution path, and which is only a convention the agent is expected to follow?