v0.2.6

Codex: the hooks now stay quiet, on purpose

If you installed with --harness=codex, re-run pets install --harness=codex to pick
this up. Claude Code users are unaffected and need do nothing.

I asked on the Codex repo whether the hooks pets installs actually fire, and a Codex user
answered with something more useful than the question: Codex reads a hook's response. A
malformed or failing hook can stop the turn before it begins, and it still exits zero, so the
symptom is a hang rather than an error.

pets was writing Claude-shaped output into that slot. hatch printed a block of ASCII art the
first time it saw a worktree, and quip printed {"systemMessage": ...}. Claude Code simply
displays whatever a hook prints, so both were fine there. On Codex, the case that would break
was somebody's first session in a new worktree - the worst one to get wrong.

So the installer now tells the binary which harness it wired, and the Codex hooks print
nothing at all. They still record everything: pets den and pets party fill up as
normal. You lose the hatch card and the end-of-turn quip, which is a fair trade against
possibly stopping a turn.

This is a precaution, not a confirmed bug report - nobody has yet run pets under a real Codex
end to end, and the question of whether unparseable stdout counts as a failure is still open.
Both are tracked in #15, and
there is now a scripts/codex-hook-probe.sh that makes reporting it a three-command job.

Thanks to the Codex user who answered; the discussion is
openai/codex#40034.

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