Inspiration
When Codex works on a long task, it compresses its memory to keep going. A rule you set, like "don't touch the auth module, it's frozen for a compliance audit," can quietly drop out of that compressed summary. The agent then violates it without knowing. The code all survives. The rule is what gets lost. This failure mode is documented in OpenAI's own codex issue tracker. I wanted a way to answer one question after a long agent session: can I actually trust that the rules I set were honoured? For regulated codebases, an agent touching a frozen module isn't an inconvenience. It's a compliance event.
What it does
CodeAnchor verifies whether a resumed Codex session still honoured its constraints. It installs as a Codex Stop hook and runs automatically when a session ends. You can also run it on demand from the CLI, or wire it into CI as a gate that blocks a merge on violation.
It parses the Codex session rollout, extracts the task's constraints (from AGENTS.md, the prompt, or a repository's CODEOWNERS file), detects where the session compacted, and checks the actual repository using git as an independent source of truth. Every violation is tagged by evidence source:
- log + git: both the session log and git confirm the change
- log-only: claimed in the log but git can't confirm it
- git-only: a protected file changed with no record in the session log at all
That last case is the core insight. A tool that only reads the agent's own log is blind to changes the log never recorded. CodeAnchor verifies against the repository, not the agent's account of itself.
How we built it
The real-schema rollout parser, the Stop hook, and the production hardening were all written in Codex sessions running GPT-5.6, with the model doing the code generation and reasoning. GPT-5.6 is also available at runtime as an optional semantic drift scorer. The key engineering decisions were mine: using git as an independent evidence source rather than trusting the session log, and bounding that evidence to the session-start commit so the tool proves this session's changes, not pre-existing ones. It builds on the pre-existing TraceMemory execution-continuity platform, adding the Codex adapter and CLI verification surface.
Challenges we ran into
- The rollout parser was first built against an assumed schema. Validating against 15 real Codex sessions revealed the true format (
{timestamp, type, payload}) and forced a rewrite. - Compaction loss compounds across repeated compactions. Analysing only the first compaction produced a false "all clear," so I fixed it to analyse every compaction and flag compounding loss.
- Bounding git evidence to the session correctly, so the tool never blames a session for a change that was already there.
- The biggest one: Codex encrypts its compaction summaries. My original approach, reading the summary to check whether a constraint survived, could not work on real data.
Accomplishments that we're proud of
- The git-only detection: catching a protected file that changed with nothing in the session log to account for it. No log-only approach can see this.
- A verifier that stays honest under uncertainty. When a constraint can't be verified, it flags for review instead of silently passing.
- 85 passing tests, including git verification against real temporary repositories and validation against 15 real Codex sessions.
What we learned
You can't trust an agent's account of itself. Codex encrypts its compaction summaries, so verifying "did the rule survive?" from the log alone is impossible on real sessions. That reframed the whole product: verify against the repository, the ground truth, instead of the agent's log. The limitation is what made the git-based approach necessary rather than just clever.
What's next for CodeAnchor
- Package it as a GitHub App and Action for one-click adoption
- Signed, tamper-evident verification reports
- More agent adapters. The verification engine is agent-agnostic, and Codex is just the first one supported.
Log in or sign up for Devpost to join the conversation.