#313 Prove parity cell: read-vs-send fingerprint block on Codex

[Anonymous]

Originally created by: fu351

The parity matrix proves read-vs-send fingerprint block on Claude Code but leaves it ◻ on Codex. The guarantee: a value read into the session earlier that later appears verbatim in an outbound payload is a confirmed read-then-send exfil and is hard-blocked. Codex runs the same spine, so it should hold there too — it needs a test to prove it.

What to do

1. Read the Claude Code sibling: tests/unit/test_hosthook_exfil_fingerprint.py (test_read_then_send_same_secret_is_confirmed_block_in_balanced). Note the deliberate use of a high-entropy, non-credential token (a named credential would block on a single call and prove nothing about the fingerprint path — the file's docstring explains why).
2. Write the Codex version driving doberman.hosthooks.codex.evaluate_pre: record the token via the post path, then send it back out in a Codex Bash command and assert a confirmed_exfil BLOCK.
3. Mark it: @pytest.mark.guarantee("read-vs-send-fingerprint-block", host="codex").
4. Mutation-check it (break the fingerprint match, confirm red, revert) and say so in the PR.
5. python -m tools.parity.generate_parity to refresh docs/PARITY.md.

Mirrors an existing, well-documented test onto Codex — self-contained.

[Anonymous]

Originally posted by: blackcoderx

Working on this — adding the Codex sibling of test_read_then_send_same_secret_is_confirmed_block_in_balanced in tests/unit/test_hosthook_codex.py, driving claude_code.evaluate_post (the only post-hook implementation in the repo) to seed the shared fingerprint store, then codex.evaluate_pre for the egress.

[Anonymous]

Ticket changed by: fu351

• status: open --> closed