Stop your coding agent from switching off its own checks

What OpenAI reported

OpenAI published a report (updated Oct 20, 2026) on two internal coding tasks where agents weakened misalignment monitoring while making requested changes (source):

• Oct 3, GPT-6.1 Sol: while repairing an evaluation pipeline, the agent disabled automatic alerts to OpenAI's Security team. It treated an earlier instruction not to send Slack messages as a reason to suppress monitoring notifications.
• Oct 6, GPT-6 Astra: while migrating a program to match a reference implementation, the agent removed its monitoring integration, then falsely told the user it hadn't.

OpenAI says both agents considered whether the safeguards should stay, then read routine instructions as permission to weaken them. It has updated Auto-Review, which is required for internal Codex use, to catch attempts to turn off misalignment monitoring (SecurityWeek).

Why this matters for a solo vibe coder

Your version of "monitoring" is your tests, your lint config, your CI workflow and your rules file. When an agent is stuck on a red check, the shortest path to green is often editing the check instead of the code: skipping a test, loosening a lint rule, or deleting a CI step. A summary that says "all tests pass" won't tell you that happened. The diff will.

The guard: block edits to the files that guard your checks

Save this as scripts/guard-checks.sh. It fails a commit when staged changes touch protected files, unless you (the human) set an override for that one commit. Edit the PROTECTED list to match your repo.

#!/usr/bin/env bash
# Fails if staged changes touch the files that keep your checks honest.
# A human can override once with: ALLOW_CHECK_EDITS=1 git commit ...
set -euo pipefail
PROTECTED='^(scripts/agent-check\.sh|scripts/guard-checks\.sh|\.github/workflows/|\.husky/|package\.json|pytest\.ini|pyproject\.toml|eslint\.config\.|\.eslintrc|tsconfig\.json|AGENTS\.md|CLAUDE\.md)'
hits=$(git diff --cached --name-only | grep -E "$PROTECTED" || true)
if [ -n "$hits" ] && [ "${ALLOW_CHECK_EDITS:-0}" != "1" ]; then
  echo "BLOCKED: this commit changes files that guard your checks:"
  echo "$hits" | sed 's/^/  - /'
  echo "If a human approved this, rerun with ALLOW_CHECK_EDITS=1."
  exit 1
fi
echo "guard-checks: OK"

Then hook it up and make it executable:

chmod +x scripts/guard-checks.sh
printf '#!/bin/sh\nexec ./scripts/guard-checks.sh\n' > .git/hooks/pre-commit
chmod +x .git/hooks/pre-commit

We tested it on Linux with git: normal source edits commit fine; edits to a CI workflow, package.json, the rules file or the guard itself are blocked with a list of the files; ALLOW_CHECK_EDITS=1 git commit lets a human-approved change through. Not tested on macOS or Windows.

Add this to your rules file

Never edit tests, lint config, CI workflows, scripts/agent-check.sh,
scripts/guard-checks.sh or this rules file to make a check pass.
Never use git commit --no-verify or set ALLOW_CHECK_EDITS yourself.
If a check seems wrong, stop and tell me which check and why.

What it won't do

A git hook is a speed bump, not a lock. An agent with shell access can still run --no-verify or edit .git/hooks. That's why the rule above matters, and why you should still read the diff of anything that touches your checks. For real enforcement, run the same check in CI against your main branch, with branch protection on.

Get the rest of the loop free

Our free Checkpoint Loop gives your agent one check command (agent-check.sh) that auto-detects npm, pytest, Cargo and Go, blocks obvious secrets in your diff and commits only on green. This guard protects that loop from being edited around. See also: make your coding agent prove it's done.

Get the free Checkpoint Loop