v0.2.7

Codex hooks work. They were never trusted, and nothing said so.

Tested against a real Codex 0.149.0 rather than reasoned about, and the answer inverts v0.2.6.

Codex will not run a new or changed hook until you trust it. An untrusted hook is
completely silent, and codex doctor does not mention hooks at all, so
pets install --harness=codex looked like it worked and did nothing. Same config, one flag
apart:

codex exec "..."                                    # nothing fires
codex exec --dangerously-bypass-hook-trust "..."    # SessionStart and Stop both fire

Mine had been sitting in ~/.codex/hooks.json for twelve days without ever running. The
installer now tells you the hooks are pending trust, which is the whole fix.

Once trusted it works properly: Codex payloads carry session_id, which is what a creature is
keyed on, so sessions register and pets den and pets party fill up as they do under Claude
Code. There is no workspace object in a Codex payload, so the den name comes from git.

v0.2.6's silencing is reverted

v0.2.6 muted the Codex hooks on the theory that Codex parses their stdout and a malformed
response could stop the turn. It does not. A SessionStart hook printing a block of ASCII
art completed the turn normally, and systemMessage turns out to be part of Codex's own hook
output schema - so the Stop hook's JSON was valid there all along. The hatch card and the quip
are back.

If you installed 0.2.6 for Codex, re-run pets install --harness=codex to drop the
now-pointless flags.

Full findings, including both payload shapes, are on
openai/codex#40034, and
scripts/codex-hook-probe.sh will repeat the experiment on another version.
Closes #15.

Upgrading

Installed with	Upgrade
Homebrew	brew update && brew upgrade parallel-harness-pets
The install script	re-run it, it replaces the binary in place
Go	go install github.com/TevvvB/parallel-harness-pets/cmd/pets@latest
A release archive	download the new one below