pushary 1.8.0

package/CHANGELOG.md

@@ -0,0 +1,1943 @@
+# Changelog
+
+## 1.8.0
+
+- **An approval you give after auto mode blocks a call is no longer lost when the agent rewords the call.** Your approval covers only the exact call that was blocked. Claude Code tells the agent only that it may retry, and an agent that sent a changed command was blocked again, so the approval you gave from your phone or the Mac notch did nothing. Pushary now refuses the first changed call and tells the agent to send the blocked call again unchanged. If the agent ends its turn without sending it, Pushary tells it to send it.
+- Claude Code no longer tells your phone and the Mac notch that it is waiting for you while its background tasks are still running. Claude Code reports itself idle after a minute at the prompt even when it will continue by itself once those tasks finish. A question from the agent still reaches you as before.
+- A prompt longer than 500 characters, or a shell command longer than about 490, no longer stops your agent at its next phone approval. The hook sent the whole text and the server refused it, so Claude Code halted with "Pushary could not create a verifiable approval" and Codex and OpenCode denied the call. The question, intent, action, blocker and agent name are now cut to what the card can show, and a cut line ends in "…". The server now does the same for every older CLI, so this fix does not wait for you to update. (#1604)
+- A line cut to fit, including a long diff, never ends on half an emoji. The server stores these lines as JSON, and Postgres refuses a half character, so the approval failed to save.
+- `pushary doctor`, `pushary upgrade`, `pushary clean` and automatic updates recognise a global install under either package name, `@pushary/agent-hooks` or `pushary`. A machine keeps the name it already has, and setup on a new machine installs the name it was run from. Nothing changes for an existing install.
+- `pushary doctor` flags a machine with both names installed globally, because uninstalling either one removes every Pushary command.
+- `pushary upgrade` no longer installs over an automatic update that is still running. It says another upgrade is running, with its process id, and stops.
+
+## 1.7.3
+
+- **Approval text never hides part of a command.** The value after a credential name is now hidden only up to the first space, quote or piece of shell syntax. 1.7.2 could still hide a command: `eval TOKEN="x; rm -rf ~"` read `eval TOKEN="[redacted]"`, `password= reboot` read `password= [redacted]`, and `rm -rf {password=x,/}` hid the `,/` that also deletes `/`. A private key block is hidden only when it holds nothing but the key. Tokens, keys and quoted values without spaces are hidden as before. A quoted value with spaces now shows what follows its first word, as in `--password='[redacted] pass'`. Logs and error reports still hide the whole value.
+
+## 1.7.2
+
+- **Approval text shows the whole command again.** A credential name that closes a quoted string, as in `grep -rl "password=" . | xargs rm -f`, made 1.7.1 redact everything after it, so the approval read `grep -rl "password="[redacted]"` and hid the `rm`. The value after a credential name is still redacted, and the rest of the command is shown.
+- **Hermes works again after an uninstall.** When setup found Pushary's own Hermes settings already in `~/.hermes/config.yaml`, left by an earlier install, its record of your config included them, and `pushary clean` put them back: approvals stayed pointed at the plugin clean had just uninstalled, and Hermes' `clarify` tool stayed off, so Hermes could not ask you anything in the terminal. Clean now recognises Pushary's own values in that record, including records older versions wrote, and removes `transport: pushary`, the `pushary` plugin entry, and the `clarify` entry that came with Pushary's transport, while restoring everything else you set. Running clean again, or after the Mac app has disconnected Hermes, no longer fails once Hermes' defaults fill the removed settings back in.
+- `pushary clean` says what it did to Hermes: "Pushary settings removed" only when it changed `config.yaml`, "no Pushary settings" when there was nothing of ours, and it skips the plugin uninstall when the plugin is not installed. `--dry-run` previews the exact change without saving it.
+- `pushary doctor` checks Hermes when Pushary set it up: that the plugin is installed in Hermes' Python and enabled, and whether approvals and questions go through Pushary. A plugin the Mac app left installed but disabled is not reported as a failure.
+- Setup on a machine without npm now says so and asks you to install Node.js, instead of printing `/bin/sh: npm: command not found` and suggesting an `npx` retry that needs npm too. Pushary still needs npm; bun, pnpm and yarn installs are not supported yet.
+- `pushary clean` tells an npm it cannot find, a package that is not installed and a failed uninstall apart, instead of calling each of them "not installed". A failed uninstall no longer ends in "Clean complete".
+- `pushary clean --dry-run` lists only the Mac keychain items and preference domains that exist, and the fx setup record only when there is one. It used to list every candidate it would try. A keychain that cannot be read, for example while locked, still counts as possibly holding Pushary's items, so clean tries them and reports a failure instead of calling the keychain clean.
+- `pushary clean` honours `NO_COLOR`.
+- Setup's agent picker shows only the names you picked once you confirm, instead of repeating every agent's description, and the transcript notice is indented like the lines around it.
+- A message you send from your phone or the Mac notch while Claude Code is running a subagent now waits for Claude Code itself. It used to be handed to the subagent's next tool call, where the main conversation never saw it.
+- When your Pushary workspace has no active subscription, Pushary now steps aside and your agent's own approval prompt decides, as it does when Pushary is not installed. Claude Code, Codex, Gemini CLI and OpenCode used to refuse gated tool calls instead, telling you to retry or that the approval was cancelled, and Claude Code questions, plan approvals and MCP forms stopped the same way. A kill switch and your deny rules still apply.
+- Your agent's terminal says once per session why Pushary stepped aside, with the link to subscribe.
+- A Claude Code or Gemini CLI session started from your phone has no prompt on your machine, so it still refuses the call, now saying the workspace has no active subscription instead of asking you to retry.
+- Pairing your phone during setup now says when your workspace has no active subscription, and to subscribe in the Pushary app or at pushary.com before running setup again. It used to say only that pairing failed.
+
+## 1.7.1
+
+- **fx asks through Pushary.** Setup now adds `"ask_user_question": "deny"` as the last rule in `~/.fx/settings.json`, which removes fx's own terminal question tool from what its agent can call, so every question goes through `mcp_pushary_ask_user`: to the Mac notch at the Mac, to the phone away from it. fx cannot forward its own prompt, so a question asked there used to wait unseen once you walked away. A rule you already set for `ask_user_question` is kept, and setup names it. The instructions in `~/.fx/AGENTS.md` now tell fx's agent to load `mcp_pushary_ask_user` with `mcp_select_tool` by exact name and to ask there even while you are at the terminal, and to ask in its reply only when Pushary hands the question back or cannot be reached.
+- fx's full-access mode (`yolo`, `full-access` or `full access`, from settings, a workspace, or `FX_PERMISSION_MODE`) ignores permission rules, so the terminal question tool stays on there; setup and `pushary doctor` say so instead of claiming questions are routed, and the instructions still steer the agent to Pushary. fx workspaces with their own permission rules replace the global ones, and setup and doctor name how many keep the question tool on. Setup reads the rules the way fx does (globs, last match wins, per-target maps) and leaves a `settings.json` fx would reject, such as one with an unknown action or permission mode, untouched and says fx ignores it.
+- `pushary clean` removes the question rule only when setup recorded adding it and it is still `deny`, so a rule of your own survives.
+- `pushary clean` now removes Pushary entries from every event in `~/.cursor/hooks.json`, not only the events the permission gate uses. The Mac app registers its bridge on session, compaction and stop events too, and those eight entries were left behind under "Clean complete". Other tools' hooks are untouched.
+- `pushary clean` now removes the Pushary block from OpenCode's `~/.config/opencode/AGENTS.md`, as it already did for Codex and Gemini. Setup wrote it and clean left it.
+- `pushary clean` removes temp files that an interrupted config write left next to an agent's config (`.<file>.pushary-<id>` and `.<pid>-<time>.pushary-tmp`), only next to the agent configs clean rewrites (your home folder, Claude Code, Codex, Gemini, Cursor, OpenCode, fx and VS Code settings), never through a symlink, and only once they are over a minute old.
+- Setup's summary no longer says "(others completed successfully)" or "Other agents will continue" when the failed agent was the only one; it names the agents that were configured.
+- Setup's progress lines no longer leave the tail of the previous frame behind ("with Codexex", "tap the notificationon"): setup uses the shared spinner, which clears the line, keeps each frame to one terminal row, and does not animate into a log when colour is forced on.
+
+## 1.7.0
+
+- **fx.** `npx @pushary/agent-hooks@latest setup --agents fx`, or ticking fx in the picker, connects Vercel Labs' fx coding agent. Setup adds a `pushary` server to `~/.fx/mcp.json` that runs the new `pushary-mcp` command, a local bridge that signs in with the key setup saved in `~/.pushary`. No key is written to fx's files, and a rotated key is used without running setup again. fx has no hooks other tools can register, so Pushary cannot answer fx's own approval prompts; fx's agent asks through Pushary's tools when it chooses to, guided by a managed block setup writes to `~/.fx/AGENTS.md`.
+- Setup adds `"mcp_pushary_*": "allow"` to the `permission` rules in `~/.fx/settings.json`, after your own rules, so fx runs Pushary's tools without reviewing or prompting for each call, the same as the other agents' auto-allowed Pushary tools. A rule you already set for `mcp_pushary_*` is kept. fx workspaces that set their own permission rules replace the global ones, and setup names how many there are.
+- Setup leaves `~/.fx/mcp.json` and `~/.fx/settings.json` untouched when fx itself would reject or refuse to edit them (comments, a trailing comma, a repeated key, or servers under a key fx ignores) and prints the command that retries only fx. It writes both files as compact JSON, the way fx does, and leaves a file alone rather than grow it past the size fx reads. It skips fx on a machine with no `~/.fx`, and on Windows, which fx does not support. fx is ticked automatically only when fx's own files are there, since other tools use `~/.fx` too.
+- `pushary doctor` checks the fx entry and that its bridge is installed, and warns when Pushary's tools are not auto-allowed. `pushary clean` removes only the Pushary server, the allow rule it added, and the instructions block.
+- `pushary setup --help` lists every agent id setup accepts.
+
+## 1.6.4
+
+- Requests to Pushary now say which client made them: the CLI version, the platform, a per-process run id, and the machine id this machine already has. They go only to Pushary's own address, never to npm or any other host, and never include file paths, keys or content. Support can then find a problem from your account instead of asking for terminal output.
+- When setup, a hook or the bridge cannot reach Pushary, cannot claim a blocked action, or stands aside for an agent it does not recognise, it now tells Pushary with a short code such as `mode_fetch_failed`. Each code is sent at most once per clock minute per machine, not per hook, even when several hooks fail at the same moment, so an outage does not add a request to every tool call. `~/.pushary/client-reports/` holds one small claim file per code per minute. A report gives up after one second. Set `PUSHARY_DISABLE_CLIENT_REPORTS=1` to send none.
+
+## 1.6.3
+
+- When setup cannot configure one of the agents you picked, the final summary now names that agent, says why, and prints the one command that retries only it, such as `npx @pushary/agent-hooks@latest setup --agents cursor`. Before, the reason was printed once in the middle of the run and the summary only said "Setup finished with 1 problem".
+- A config file setup refuses to rewrite, such as a `~/.cursor/hooks.json` or `~/.claude/settings.json` with comments or a trailing comma, is still left untouched and backed up next to the original. Fix or remove it, then run the retry command; it reuses your saved key and does not pair your phone again.
+- `setup --json` adds `agentFailures`: one entry per agent that failed, with its reason.
+- Setup's report to your own Pushary workspace now says which agent failed and why (the agent and a reason code only, never a file path or file contents), which check decided the exit code, and the CLI version. Support can then see what went wrong without asking you to paste terminal output.
+
+## 1.6.2
+
+- "Allow Bash for this session" now still asks before rsync deletes files: `--del`, `--delete-delay`, `--delete-missing-args`, `--remove-sent-files`, and a long option shortened to a unique prefix such as `--delete-dela`. It also still asks for `git checkout -f`, `git checkout <ref> -- <path>`, `git switch` with `-f`, `--force` or `--discard-changes`, branch resets (`git checkout -B`, `git switch -C`, `git branch -f`, `-D`, `-M`, `-C`), and `redis-cli flushall` or `flushdb` in any letter case, wherever the flag or word appears. Before, the grant ran these without asking. `git checkout HEAD file.ts`, which overwrites a file without a `--`, still runs under the grant.
+- The same commands now ask even when your own Claude Code allow rules cover them, such as `Bash(git:*)` allowing `git checkout origin/main -- package-lock.json`. Pushary still leaves every other command those rules allow to Claude Code.
+
+## 1.6.1
+
+- Pushary-launched Codex sessions can answer supported questions from inside MCP tools through Pushary. Invalid answers and cancelled requests never become approval. This does not connect existing Codex Desktop Computer Use permission dialogs.
+- Claude forms with rules Pushary cannot preserve now stay in the native client instead of silently losing those rules.
+
+## 1.6.0
+
+- Pushary no longer asks about a Claude Code command your own Claude Code allow rules already cover when only a Pushary default would have asked. Risky commands still ask: destructive, network and data-loss commands, and anything whose effect cannot be read from its text, such as `bash -c`, inline interpreter code, `xargs` or a `#` comment. If Claude Code prompts anyway, the approval still reaches your phone.
+- Your Claude Code rules are read from your managed, user and local settings. A repository's committed `.claude/settings.json` can only add asks and denies, so a cloned repository cannot switch Pushary off.
+- After three approvals of Bash in a row in one session, the phone and the Mac offer "Allow Bash for this session". Risky commands still ask, and a command the grant holds back is delivered exactly as it was before the grant.
+- "Approve for this session" no longer saves a rule for a risky command, or for a wrapper such as `bash -c` or `git -C` that would cover every command after it.
+- A preset you picked in Policies now applies on sites that have an Approvals mode set, which is nearly all of them. The Approvals mode still decides where an approval goes.
+- A call your team routes to an approver keeps that approver, whatever your own Claude Code settings allow.
+- An automatic update whose agent configuration refresh fails now stays pending and retries, instead of reporting success.
+- A newer release now replaces a pending upgrade whose refresh keeps failing, so updates never stop. `pushary upgrade` prints what failed instead of a stack trace.
+- Setup, upgrade and doctor no longer run a Codex binary that sits inside an app bundle when `codex` on your PATH points there directly or through a symlink.
+
+## 1.5.1
+
+- Setup no longer stops at a Codex version. It writes the Pushary hooks, asks Codex to trust them, and checks Codex's answer. It used to trust the hooks itself only up to Codex 0.155.1, and on anything newer told you to open Codex and trust them by hand.
+- Pushary asks Codex only when you run setup, upgrade or doctor yourself at a terminal, only through the `codex` command on your PATH, and only if Codex has been opened on this machine before. It never starts the Codex inside the ChatGPT app, and never while a hook is running.
+- If Codex does not accept the trust, setup says so and tells you to open Codex, run `/hooks`, and choose Trust for the Pushary hooks. When Codex is not asked, setup says why in one line and keeps the trust entries it wrote itself, as it did before.
+- `pushary upgrade` asks Codex the same way after it refreshes the Codex hooks. The daily automatic update refreshes the hooks and writes the same trust entries but does not start Codex, so an install left untrusted by the old version limit is fixed on its next update either way. Machines older than 1.5.0 do not update themselves: run `npx @pushary/agent-hooks@latest upgrade` once.
+- `pushary doctor` shows what Codex itself reports for each Pushary hook: trusted, untrusted, modified, not listed, or turned off. When Codex is not asked or cannot be asked, doctor says so and uses its own check instead.
+- Pause automatic updates on Linux to preserve phone-started sessions during daemon replacement.
+- Retry incomplete configuration and daemon refreshes after an automatic installation, including when the installed version is already current.
+
+## 1.5.0
+
+- Pushary now updates itself in the background. When an agent session starts, it checks at most once a day for a newer version within the same major version, installs it into the global npm folder your hooks already run from, and refreshes each agent's config the way `pushary upgrade` does. The session never waits for it. A new major version is shown in `pushary doctor` and left for you to install.
+- Turn it off with `pushary upgrade --auto=off` (and back on with `--auto=on`), or set `PUSHARY_DISABLE_AUTOUPDATE=1` in the environment your agents start from.
+- It does not run on Windows yet, in CI, or for a copy run through `npx`, a plugin, or the Mac app. It never uses `sudo`: if npm cannot write to the global folder, the attempt is recorded as failed and nothing changes.
+- This only reaches machines on 1.5.0 or later. To get there, run `npx @pushary/agent-hooks@latest upgrade` once.
+- `pushary doctor` shows whether automatic updates are on and the result of the last check, and `setup` and `doctor` tell you once when Pushary has updated itself.
+- `pushary doctor` no longer calls a build newer than the npm release out of date.
+- The commands the CLI prints for you to copy now say `npx @pushary/agent-hooks@latest`. Without `@latest`, npx runs whatever older version is installed globally.
+- A failed npm install now reports npm's reason, such as a permission error, instead of a line like `syscall mkdir`.
+
+## 1.4.2
+
+- Setup trusts the Pushary hooks for you on Codex up to 0.155.1. It used to stop at 0.147.0, so on a newer Codex it wrote the hooks without trusting them, Codex never ran them, and setup still said it was done.
+- On a Codex newer than the last version Pushary checked, setup says so in one line and tells you to open Codex and choose Trust for the Pushary hooks.
+- The phone QR stops waiting 10 seconds before the pairing code expires, so the code is cancelled cleanly on a timeout.
+- After a minute at the QR with no scan, setup offers the browser sign-in: Ctrl-C, then `npx @pushary/agent-hooks setup --connect browser`.
+- A kill switch or standing deny on Codex now appears in your decision history, as it already did for Claude Code. If that record fails to send, it is sent again on the next matching denial.
+- `clean --everything` also removes the sign-in session the Mac app now keeps in the keychain.
+
+## 1.4.1
+
+- `clean` masks credentials in shell lines it cannot rewrite, including output you might send to support.
+- `clean --everything` stops before changing configuration if the Mac app refuses to quit. Keychain access failures are reported as incomplete cleanup; missing items alone count as absent, and permission prompts can finish.
+- Cleanup passes discovered preference domains, app paths and keychain services as literal command arguments. A foreign skill named `pushary` is preserved unless the skills.sh lock identifies it as ours.
+
+## 1.4.0
+
+- `pushary clean --everything` removes what the Mac app set up as well as what the CLI did. It quits the app, then removes its keychain items, preferences and caches, the editor extension it installs in Cursor and VS Code, and the skill's registration in `~/.agents`. A plain `clean` still leaves an installed Mac app alone, and now says so instead of printing "Clean complete." over a key it kept.
+- `clean` tells you to run `unset PUSHARY_API_KEY` when your terminal still exports the key. Without it, `setup` in the same terminal signed you straight back in as the account you had just removed.
+- `clean` no longer leaves your key behind in its own backup of your shell profile, in earlier copies of the Cursor plugin, or in the line `pushary logout` comments out.
+- A line in your shell profile that still sets a real key, in a form `clean` will not rewrite, is reported as left behind rather than skipped.
+- `clean`, `doctor` and `setup` name business@pushary.com and the Discord when they leave something broken.
+- A plain `clean` after you delete the Mac app removes what the app left behind. It used to take the app's leftover locator file as proof the app was still installed, and kept every hook pointing at it. In Cursor those hooks deny whatever reaches them once there is no app to answer.
+- `clean` removes the Pushary entry and its key from Claude Code's own backups of `~/.claude.json`, not only from the live file. Restoring one of those backups used to put a working key straight back. A backup from before setup keeps whatever you had there.
+- A file edit no rule was written for goes straight to the agent's own prompt instead of waiting for your phone first, in Claude Code's default mode and when Codex is about to ask. Over 35 days these were asked 224 times and answered from a phone twice. A rule you wrote, a preset or mode you picked, and a scope contract still reach your phone, and runs that bypass permissions are unchanged, because there is no prompt to fall back to.
+- A kill switch or a standing deny enforced on this machine now appears in your decision history, as it already did through the Mac app. Only what the machine allowed was recorded before.
+- Qwen Code, CodeBuddy and Qoder keep the answer you give on a permission prompt. Devin's patch and MCP calls reach the gate that was installed for them. A hook naming an agent Pushary does not recognise with `--source` stands aside, as it already did with `--agent`, rather than acting as Claude Code.
+- `doctor` reads hook commands written in quotes or with `--source`, and tells a malformed MCP registration apart from a configured server.
+- A hook payload that is not the shape it claims to be is refused before it can change anything.
+
+## 1.3.1
+
+- Keep human-review policies effective inside shell chains, and refuse automatic approval of quoted command substitutions.
+- Check kill switches and standing denials before rejecting unreadable tool targets. Check every file in a patch; ask the agent to split a batch that crosses scope.
+- Preserve symlinked agent configuration files during atomic updates.
+- The installed skill recognizes file-edit capabilities across agents, including Codex patches.
+- `pushary doctor` warns when hooks are registered for an agent this version has no profile for. Every one of them stands aside, so nothing on that agent is gated or recorded until you upgrade.
+- A hook that stands aside because it cannot resolve `--agent` says so in the documented `[degraded]` shape, so a stand-aside is countable instead of invisible.
+
+## 1.2.0
+
+Nothing to run. These are the gate's own rules, tightened where they were guessing.
+
+- A shell command Pushary cannot read is no longer judged on the loosest rule that fits. A tool whose command arrives under a key we do not recognise used to fall through to a bare `Bash` rule, which is always the permissive one; a path in the same position already refused to be judged. Both now say they have no opinion and let the agent ask you. An agent that names its command differently can declare the key instead of losing the gate.
+- An `--agent` Pushary does not recognise stops the hook rather than turning it into Claude Code. A typo in a registered command used to fetch Claude's policy and file the session under Claude's name. Every hook now stands aside and says why, because acting as the wrong agent is worse than not acting.
+- `pushary doctor` calls your hooks intact only when all of them are. It used to accept any single surviving hook as proof, so a config wiped down to one entry read as healthy.
+- Setup no longer counts its own folder as proof you have an agent installed. The directory it writes the config into was being read back as evidence the vendor was there, so ticking an agent once made it look installed forever. Only the agent's own binary counts now.
+- The slowest call we make to Stripe carries its own deadline. Every Stripe call was bounded at five seconds, which is right for the checkout path and too tight for an invoice preview.
+
+## 1.1.0
+
+Nothing to run if you are already set up. `pushary setup` writes the new skill;
+so does opening the Mac app, which carries its own copy.
+
+- A scope boundary now works for a run that changes no files. `propose_scope` takes `promises`: boundaries that are not paths, such as who you will not email, what you will not spend, and which systems you will not open. They are shown to the approver as "Promised, not checked", recorded in the ledger, and never enforced, because the gate judges a file path and these have none. Saying so is the point: the tool used to return `ratified: true` for a marketing or support run whose contract matched nothing.
+- The tool now reports what it will actually check. `enforces` lists what the contract *contains* that can be checked, and an empty array means nothing in it is. `hookSeen: false` means no hook has ever reported that session id, so the contract is stored under a key the gate will never read. Both were previously invisible: a contract that enforced nothing looked exactly like one that enforced everything.
+- Four glob rules that matched nothing are repaired when they are proposed. `customers`, `docs/`, `**/.env*` and `**/*.test.ts` each validated clean and matched no file. The last two shipped as our own documented examples, so anyone who copied them to protect a root `.env` protected nothing. The missing pattern is added at proposal time rather than by loosening the matcher, which would have widened every contract already live.
+- The approval card is budgeted from the restrictive half outwards. The allow list is the only part that grows, so cutting one joined string at the end dropped the off-limits line, the definition of done and the promises first: exactly the half a person needs in order to say no. Agent-supplied text is flattened to one line, so a promise can no longer forge a row the server wrote.
+- The editor gates carry the scope path again. The Cursor and VS Code gates contained no reference to it, so approving a breach never widened the contract and every further file in the same area asked again. An over-length value is dropped rather than sent, because `ask_user` caps it and a rejected call fails closed.
+- A scope breach says so on the card. A breach judged by the server reached the person as a plain "Allow Edit foo.ts?", with nothing saying a boundary they personally ratified had been crossed.
+- `pushary doctor` names a tool that can take your hooks away. cc-switch replaces `~/.claude/settings.json` wholesale when you switch provider, so Pushary stops firing with no error and nothing to see. Doctor says so while the hooks are still there, and says the mechanism rather than blaming it once they are gone. It diagnoses only: it never rewrites a config because somebody else's software is installed.
+- The installed skill goes to 0.10.0. It breaks a task into steps before asking anything, settles every fork a file or a command can answer, and asks the rest as one numbered round. A question in the terminal is free and a push is not, so the whole round goes to the terminal when you are there and only the blocking one crosses to your phone. Setup now branches on the machine instead of assuming one path.
+
+## 1.0.0
+
+Run `pushary setup` and tick the agents you use. Five more are on the list: Qwen Code, CodeBuddy, Qoder, Droid and Devin CLI. Nothing changes for an agent you already had wired.
+
+- Gate five more agents on their own hooks, not on good intentions. Qwen Code, CodeBuddy, Qoder, Droid and Devin CLI each register the same events Claude Code does, in the file and the spelling that agent uses, and each returns a verdict that agent obeys. Shell commands, writes and edits go through your policy and your phone the same way they always have. Twelve agents are now enforced rather than cooperative.
+- Devin answers in its own dialect. It reads `{"decision":"approve"|"block"}` where the others read Claude's `permissionDecision`, so the verdict is written the way each agent reads it. A stop from your phone carries across both: it ends the turn rather than declining one tool call and letting the next one through.
+- Two tools are deliberately not claimed on Devin. A question answered on your phone comes back as rewritten input, and Devin's reply shape has nowhere to put it, so asking there would tell the agent "approved" and hand it the question you already answered. Pushary stands aside instead, and Devin asks you itself.
+- Read the file out of a patch before judging it. Droid edits by sending a patch rather than a path, and a rule written for a file cannot match a patch body. A single-file patch is now resolved to the file it touches, so `Edit(**/.env)` denies it. A patch over several files is not judged at all and goes back to the agent to ask, because one answer cannot cover several files honestly.
+- Never judge a call whose target cannot be read. If a tool names its file under a key Pushary does not recognise, the only rule that could match is the one written for the tool alone, and that is always the looser one. Pushary now says it has no opinion and lets the agent ask you, rather than approving on a rule that was never meant for that file.
+- Leave a config alone when it is not the shape Pushary knows. These are five other vendors' files. Where a hook list is something other than a list, setup now names the key, changes nothing and reports the agent as skipped, instead of replacing what it found. It already refused to rewrite a file that would not parse; this is the same care for a file that parses and is simply shaped differently.
+- Keep the directory a shell command names. An approval card that said `rm -rf *` without saying where it ran was describing a different command than the one about to happen.
+
+These five rest on each vendor's documentation and our own round trip; no vendor binary was installed to confirm them. If setup reports one as skipped, that is the check above doing its job, and the message names the key it did not recognise.
+
+## 0.99.0
+
+Nothing to run. This release is the part that runs itself: the repairs below happen on the next session start, on the machine that already has them wrong.
+
+- Switch on a hold that an older release registered without its proof. `PermissionDenied` and Codex's `Stop` hold only when their registration carries `--hold-budget`, and a registration written before 0.97.0 is present and looks correct, so nothing noticed it had stopped holding. Until now the repair was `pushary upgrade`, run by hand. Claude Code's registration is now checked on every session start whether or not Claude Code itself has changed, and Codex's is checked on its own session start, which had no repair of any kind before this. An auto-mode block or an auto-reviewer denial can be answered again without anyone being told to run a command.
+- Hooks the macOS app wrote are still left to the app, on both agents. It repairs its own, and rewriting them here would point them at a binary the app does not install.
+- Read a hold budget that is not this release's as no proof, which is what the Mac app has always done. `pushary doctor` says a hook "carries no current hold budget" rather than that it predates one, because now it can mean either.
+- Never replace an absolute path in a hook command with a bare name. When the bin directory cannot be found, which is what a GUI-launched agent or an nvm switch does to `npm prefix -g`, the rewrite is refused and the registration you already have is left alone. A hold that does not hold still works less well than it should; a hook command that no longer resolves does nothing at all, and the rewrite touches every event at once. `pushary upgrade` is a person at a prompt and is unchanged.
+- Write Codex's `config.toml` atomically, carrying its permissions over. It is now written from a session-start hook, and two sessions starting at once must not leave it half written. An atomic write replaces the file rather than its bytes, so the mode is copied across by hand: this file holds your API key, Codex creates it private to you, and it stays that way.
+
+## 0.98.0
+
+Run `pushary setup` so the instruction block in Codex's AGENTS.md, GEMINI.md and OpenCode's AGENTS.md carries the new line. `pushary upgrade` rewrites hooks and trust, not instruction files.
+
+- Say the Codex rescue in your own voice. When you allow a command the auto-reviewer denied, the turn now resumes with "I approved this command in Pushary after the auto-reviewer denied it", because Codex hands that text to the model as your own turn. The old third-person wording read as a tool claiming someone else's permission and the model refused to run the command again.
+- In the instructions Pushary writes, say that rerunning the exact command you approved after a denial is the approved path and not a bypass of an enforced gate. It sits beside the line that says never to bypass one, which is what the old wording collided with. Tied to the hook result rather than to "when Pushary reports", so a page or a diff reciting the sentence beside a command is not a rule telling the model to run it.
+- Register the Cursor gate where it already sits, like every other writer, instead of taking it out and adding a fresh one on the end.
+- Drop the Codex trust key of a duplicate of ours when a rewrite collapses it. Otherwise the tool that moves up into that index inherits a hash it cannot match, and Codex reads its hook as Modified and silently stops running it.
+- `pushary doctor` no longer says another tool's hook "runs before ours" or "runs after ours". No agent runs the hooks on an event in a defined order, so the line names who else holds the event and for how long, and claims nothing about which goes first.
+
+## 0.97.0
+
+Requires the Codex auto-reviewer handling in `POST /api/agent/gate`, Codex bodies on `POST /api/agent/blocked-action/claim`, the `blocked-action/v2` Claude identity and `sessionCwd` on the gate request before rollout. Run `pushary upgrade` so Claude Code's `PermissionDenied` and Codex's `Stop` are registered with the hold budget, Codex gives `Stop` the full hook budget, and Codex trusts it again.
+
+- When Codex runs with `--approve-for-me`, stop asking you before its auto-reviewer. `PreToolUse` and `PermissionRequest` have no opinion under the reviewer, after the kill switch and a standing deny, so nothing the reviewer allows reaches your phone.
+- When the auto-reviewer denies a shell command, hold the turn end and ask once whether to allow that exact command. A yes continues the turn, Codex runs the same command again, and the retry skips the reviewer once. A no, or no answer, lets the denial stand. Denials of `apply_patch` and MCP calls are not asked about yet. The request names the session's directory as well as the command's, so the card can say where the command runs.
+- Hold a blocked call only when the hook can prove its host waits that long: the `--hold-budget=<seconds>` argument its registration now carries, or the budget the Mac app hands down in `PUSHARY_HOLD_BUDGET_SECONDS`. The hold never waits past that budget less its reserves. Without proof, which is an install registered before this release, the Claude plugin's older entry, an update that skipped `--finish-upgrade` or a Mac app built before it, a Claude block sends the "Auto mode blocked <tool>" notification instead, and a Codex turn end reads no denial, so it is still asked about once the hook is upgraded.
+- Build the `blocked-action/v2` identity for a Claude call, which includes its working directory, so the retry's hint and claim match the server's grant. A Claude call with no working directory is not asked about. Keep the retry hint for the grant's two minutes rather than ten.
+- `pushary doctor` warns when a `PermissionDenied` or Codex `Stop` registration carries no hold budget.
+
+## 0.96.0
+
+Requires the auto-mode block handling in `POST /api/agent/gate` and the `POST /api/agent/blocked-action/claim` route before rollout. Run `pushary upgrade` so Claude Code gives the `PermissionDenied` hook the full approval window.
+
+- When Claude Code's auto mode blocks a call, hold the agent and ask once whether to allow that exact call. A yes retries it and the retry runs. A no, or no answer, lets the block stand.
+- Stop sending a separate "Auto-mode blocked" notification and remove `PUSHARY_AUTOMODE_RETRY`. The server now decides whether a block is asked about, so the kill switch, a standing deny and your approval mode all apply.
+
+## 0.95.8
+
+- Stop `clean` leaving a key it installed in Claude Code, Codex and Gemini when the Mac app is installed. An entry is kept only when its key is the one the Mac app holds; when the app has never signed in, the key setup recorded is removed.
+- Keep `~/.pushary/bridge-auth` when the Mac app is installed. `clean` used to delete the app's bridge key.
+
+## 0.95.7
+
+- Let Gemini's own prompt decide in When I'm out when Pushary cannot create the approval question, instead of refusing the call. Every time still refuses, and says Pushary could not create a verifiable approval.
+- Refuse approvals an unattended Gemini bridge cannot show locally with a specific reason (no local input, no phone answer in time, handled on the machine, no device connected), instead of passing them to Gemini's unexplained headless denial.
+- Withdraw the phone question before a Codex bridge gives up on a Terminal or Updates question, so an answer that arrives during the withdrawal still counts.
+- Describe what happens when you don't answer in `pushary doctor` and `pushary wait` in the current mode words: When I'm out asks your phone when you are away or Pushary cannot tell, then hands back to the agent's own prompt.
+
+## 0.95.6
+
+- Separate synthetic answer tests from real hook activation and report the actual answering surface.
+- Cancel known pending diagnostic questions on interrupted or unanswered exits without fabricating approval.
+- Add Claude Code activation evidence for a unique scratch-file approval, correlated with the observed tool result.
+- Report managed-control readiness separately from hook configuration and phone delivery, refreshing credentials, service state and remote proof after interactive waits.
+
+## 0.95.5
+
+- Preserve the full approval window while allowing the final poll time to return; keep late denials and cancellation authoritative.
+- Bundle corrected VS Code read classification and Cursor file-gate fallback, including native shell/MCP prompts when a gate script is missing.
+- Share Claude hook ownership with the server to avoid duplicate decisions while retaining native-mode handoff.
+- Keep supported-agent setup guidance and policy scope aligned with the shared agent manifest.
+
+## 0.95.4
+
+- Keep inactive/offline login results truthful, with one JSON result and no duplicate key minting to recheck readiness.
+- Preserve authentication blocks until readiness is verified; recover the verified saved account while respecting explicit control off.
+- Keep setup and CLI help accurate about approval delivery modes.
+
+## 0.95.3
+
+- Verify account readiness after phone pairing before activating approvals or starting managed services.
+- Preserve useful configuration while offline, with consistent unverified output and exit codes instead of a successful activation claim.
+- Reuse the saved key when setup is rerun after payment or connectivity recovers; preserve explicit phone-start opt-outs.
+
+## 0.95.2
+
+- Add `pushary cowork` and connector-only setup aliases for Claude Desktop, Chat and Cowork, without acquiring a CLI key or installing local hooks.
+- Bundle the canonical Cowork skill and expose setup steps, standing instructions and a real user-answer test prompt.
+- Explain cooperative connector limits and keep native permission hooks and managed session control separate.
+
+## 0.95.0
+
+Requires the additive session-control and encrypted transcript-preview server routes before rollout.
+
+- Capture opted-in direct Claude terminal transcripts through the daemon, including Mac-owned hooks when this CLI is installed. Normalize explicit Codex rollout paths.
+- Keep native terminals open for ordinary phone messages; require explicit phone takeover and resume the verified native session identity.
+- Wait for native process exit before SDK control, preserve queued instructions across mode changes, and acknowledge only accepted commands.
+- Stream redacted, encrypted SDK text previews using the existing acknowledged session key; completed transcript records remain authoritative.
+
+## 0.94.0
+
+- Align Node compatibility with setup dependencies; unsupported runtimes receive an upgrade message before a command loads.
+
+## 0.93.1
+
+- Attach stable usage report IDs and preserve the report timestamp across retries so the server counts a replay once.
+- Report restricted agent-key scope accurately and fail closed on unknown identity scopes.
+- Requires the additive server accounting and key-capability changes from #1303 before rollout.
+
+## 0.93.0
+
+Requires Node.js 20.3.0 or newer for shared cancellation signals.
+
+- Register the expanded Claude and Codex hook coverage from the September 4 changes; preserve child-agent identity during compaction.
+- Share one deadline across mode lookup, question reconciliation, event reporting, and command acknowledgement. Retain unresolved question markers for retry.
+- Deliver queued phone instructions on UserPromptSubmit and keep observational hooks from consuming them.
+- Redact credentials in notification activity, phone pushes, and unrecognized failure messages.
+- Diagnose modified Codex hook definitions against their installed trust hashes.
+
+## 0.92.1
+
+### A rejected key is an answer, not an empty poll
+
+`pollAgent` returned `{ command: null, mode: null }` for every non-OK response,
+so a 401 was indistinguishable from a healthy poll with nothing queued. That
+landed on the success branch of `startCommandPoller`, which resets `errorStreak`
+to zero, so the backoff never engaged and the wrapper polled a dead key at the
+idle cadence forever. Because `mode` was null, `onModeState` never fired, and
+`onModeState` is the only place `dualMode` sets `killed` and stops the active
+leg. A wrapper whose key the server rejects therefore reported `kill=false` to
+itself indefinitely: remote stop could not reach it, phone messages never
+landed, and nothing was printed.
+
+`PollResult` now carries `rejected`, set only for 401 and 403, which is the same
+line `fetchModeState` already drew between an answer and a blip. A rejected poll
+takes the error path, so the existing exponential backoff applies, and the
+wrapper prints once that remote stop and phone messages are not active. A 500 or
+a dropped connection is still a blip and still retried at the normal cadence.
+
+A rejected response is also no longer trusted for its contents: neither the
+command nor the mode state it carries is applied.
+
+## 0.92.0
+
+### A Claude Code upgrade registers the events it just gained
+
+`CLAUDE_HOOK_EVENTS` gates each hook on the oldest Claude Code that understands
+it, and the supported set was filtered by the version detected when the hooks
+were written. Nothing re-ran that filter except `pushary upgrade`, so an event
+your Claude Code gained reached you when Pushary next shipped rather than when
+Claude did: the hook sat in the table, supported by your CLI, and unregistered.
+
+SessionStart now asks the question, because that is the moment an upgrade becomes
+observable. The answer costs about 5 ms of local reads and writes nothing unless
+the event set actually moved. A machine wired against an older Claude picks up
+the newer events on its next session.
+
+It leaves three things alone. Hooks the macOS app wrote are never rewritten: the
+app owns that wiring and the CLI's writer would replace its locator with the npm
+bin. A patch bump that adds no events refreshes only the receipt, so settings.json
+is not rewritten every time Claude Code ships. A machine with nothing wired is
+left to `setup`.
+
+The settings write is now atomic — temp file, fsync, rename — because several
+sessions can start in the same moment and two plain writes interleaving is a torn
+settings.json.
+
+## 0.91.0
+
+### Setup adopts the key the Mac app is already signed in with
+
+The Mac app authenticates through Clerk and writes its API key into every agent
+config it wires, but never into `~/.pushary/config.json`. Setup's key ladder did
+not look there, so a Mac the app had already connected still fell through to the
+pairing QR and minted a second key for an account that was already live.
+
+The ladder gains one rung between the environment and pairing: a key the Mac app
+wrote, probed against the server exactly like the stored and environment rungs
+are, and skipped whenever `--key` was passed or `--connect app` was typed. Both
+of those still mean what they meant.
+
+## 0.90.2
+
+### The Mac app and CLI coexist without a hook takeover
+
+Setup keeps live Mac app hooks in place without prompting, while verifying that
+the app and mobile setup belong to the same Pushary tenant. Distinct keys for the
+same tenant coexist; a different or unverifiable account is reported without
+silently replacing the app's wiring. Stale app hooks are repaired by the CLI.
+
+An explicit `--take-over-hooks` remains reversible. Clean restores the app's
+hooks, MCP credentials, and Codex trust from a retry-safe receipt before removing
+the CLI, and dry runs no longer claim that restoration already happened.
+
+## 0.90.1
+
+### Daemon logs distinguish health from failure
+
+Successful daemon startup and phone-requested launches now go to the normal log,
+leaving the error log for failures that need attention.
+
+### Command-store tests never touch live agent state
+
+The pending command store accepts an explicit directory override. Tests use a
+fresh temporary store, so parallel and sandboxed runs cannot read, overwrite, or
+prune commands belonging to a real agent session.
+
+## 0.90.0
+
+### A hook that needs an answer is allowed to wait for one
+
+Claude Code hooks are now registered at the 600 second budget Claude itself
+allows, so a policy that waits two minutes for a phone approval is no longer cut
+off at 120 seconds and turned into a denial the user never saw. Anything a hook
+does that is not a decision keeps its short timeout.
+
+A phone card is now withdrawn when the tool it guarded completes or the agent's
+own client denies it, so an approval cannot arrive for something that already
+finished.
+
+### The prompts that never reached the phone
+
+Codex permission requests are no longer filtered by a shell matcher, so a browser
+use request, a managed network request and an MCP tool request all reach the
+phone the same way a shell escalation does. Codex in bypass mode now decides
+before the tool runs rather than after it, which is what push-first has always
+meant everywhere else.
+
+Gemini reports its turn boundary through AfterAgent and its teardown through
+SessionEnd, so a finished Gemini turn is a finished turn rather than a session
+that stayed open.
+
+A finished subagent now ends its own session instead of ending its parent's, and
+appears under the session that started it. Context compaction is reported as
+itself rather than as a tool that ran.
+
+Pushary's own tools are never gated by Pushary, on the server exactly as in the
+hook, so asking the user a question can no longer wait on approval to ask it.
+
+### Sessions end, and a daemon that cannot log in says so
+
+A session that goes quiet is closed rather than left standing forever, and the
+daemon reaps the sessions it started. `pushary daemon status` lists what it is
+holding, how old each one is, and how much memory it is using.
+
+A daemon whose key is rejected now records that and stops, instead of restarting
+into the same rejection until something notices. `pushary doctor` says the daemon
+needs a login, and logging in clears it.
+
+### Setup and doctor tell the truth about this machine
+
+`pushary doctor` names the other tools holding the same agent hooks and how long
+each of them waits, checks that the bridge the Mac app installed can be found,
+and reports which Node the hooks will actually run under.
+
+`pushary setup` gained `--verify none` for an unattended install, prints what it
+would also do during a dry run, offers a way out of pairing, and can take over
+hooks another tool is holding with `--take-over-hooks`. `pushary mode` now sets a
+site's mode permanently unless told how long to keep it.
+
+### Machine identity and clean
+
+`pushary clean` leaves the machine identity shared with the Mac app intact, keeps
+one entry rather than two, and treats the identity file as the CLI's to own and
+the app's to read. Transcript sync seals its recovery ledger and admits a gap
+rather than syncing bookkeeping around it.
+
+## 0.89.13
+
+### Synced transcripts survive large turns and restarts safely
+
+Oversized file reads and diffs are shortened before encryption instead of being
+rejected by the server, with the removed UTF-8 byte count recorded in the turn.
+Stable HMAC identifiers prevent transcript contents leaking through record ids,
+and a resumed session reuses its persisted encryption key rather than conflicting
+with the key already registered for that session.
+
+Transcript recipients are now pinned on first use and later key changes stop sync
+until the user explicitly runs `pushary transcripts trust --rotate`. First use
+also fails closed when that pin cannot be stored, so no session key is wrapped to
+an unrecorded recipient. New sessions can independently wrap their key for the
+owner's phone and an optional audited compliance-recovery recipient; installations
+without one remain compatible.
+
+## 0.89.12
+
+### Phone control installs as a native service, without a VM
+
+Fresh setup enables phone-start when a supported provider and the operating
+system's own per-user service manager are available: launchd on macOS, systemd
+on Linux, and Task Scheduler on Windows. Existing installs keep their stored
+choice. Service replacement is transactional, verifies the new process before
+committing, and restores the previous running or stopped state on failure.
+
+Claude Code, Codex and Gemini sessions started from the phone now use the same
+supervised control path. Setup checks both the local heartbeat and the server's
+view of the machine before calling control ready.
+
+### Fresh and partial installs repair themselves
+
+Setup now verifies every global command, its local JavaScript imports, and the
+Cursor and VS Code runtime assets before reusing an installed version. A
+same-version package missing any of them is reinstalled instead of failing the
+same setup forever. Fresh installs also cover Codex on Windows and recover from
+partially configured providers without disturbing unrelated settings.
+
+### The CLI and macOS app keep their own wiring
+
+Cursor setup writes one gate per event even when the other installer ran first.
+`pushary clean` removes the CLI gate while preserving the app's bridge, and
+`pushary doctor` validates the MCP entry from the installer that actually wired
+Cursor. This keeps mixed CLI/app machines working and avoids false repair
+failures on app-only installs.
+
+### Transcript control works in every shell
+
+Setup discloses encrypted transcript sync and its audited compliance-recovery
+path before enabling it for a new install; older installs remain off until setup
+runs again. `pushary setup --transcripts on|off` now provides the same persistent
+choice in POSIX shells, PowerShell and Command Prompt. The existing
+`PUSHARY_TRANSCRIPTS` environment override remains compatible.
+
+## 0.89.11
+
+### Phone-spawned Codex and Gemini sessions record their conversation again
+
+Both bridges relay their turns by default and stop only when told to. The
+launchers told them to stop on every run: the value they passed was an equality
+test against an environment variable nobody sets, which is false whenever it is
+absent and never the "unset" the bridge was looking for. The relay was therefore
+never built, and a session started from the phone had nothing to show but its
+task title. The opt-out is now passed only when it is asked for.
+
+### An agent standing by stops reading as working
+
+`pushary claude` and the Gemini bridge reported that a session had started, that
+it was still alive, and that it had ended, with nothing in between. Their
+heartbeat kept resetting the clock that would otherwise have aged the session out
+of "active", so the phone showed a working agent for one that had been waiting at
+its prompt since its last reply. That is exactly when someone is looking at the
+screen deciding whether to send it something. Both now report the turn boundary
+they already detect, as the Codex bridge always has.
+
+### Taking a session over from your phone says so, and is ready when you ask
+
+An instruction from the phone hands the terminal to Pushary so it can drive an
+agent that would otherwise sit idle. That has not changed. The handover is now
+announced before the session is signalled, instead of the terminal appearing to
+lose its agent for no visible reason. The Agent SDK is resolved when the session
+starts rather than during the handover, so the wait is gone, and a machine that
+cannot reach npm reports the instruction as undelivered instead of accepting it
+and then dropping it. An instruction that is dropped now says it was.
+
+## 0.89.10
+
+### Phone control delivery is crash-safe
+
+Phone instructions now use per-command receipts across polling and relay
+delivery. A process restart acknowledges the recorded outcome instead of
+silently losing or repeating an instruction, multiple queued commands no longer
+overwrite each other, and expired receipts are pruned when new commands arrive.
+
+### Setup and clean reverse only Pushary-owned changes
+
+Setup records the Claude and Hermes configuration it replaces. Clean restores
+that prior shape without deleting later user edits, and retains the receipt when
+service removal, Hermes rollback, or plugin uninstall is incomplete so a retry
+can finish safely. Installations created by older releases keep their compatible
+best-effort cleanup path.
+
+### Native permission modes keep their intended owner
+
+Codex now reads the permission mode it already reports, and Claude
+`PermissionRequest` remains answerable from Pushary after the agent itself asks
+for a human. Kill switches and standing denies still take precedence.
+
+## 0.89.9
+
+### Setup proves managed control reaches the server
+
+The background daemon now records successful heartbeats separately from
+successful control-queue responses. Setup and upgrade wait for both before
+reporting managed control ready, and doctor reports either missing proof.
+
+An authenticated, once-per-minute challenge round trip gives the server the
+same readiness evidence without launching an agent or changing queued work.
+Machine status exposes that observation additively so current clients keep
+their existing fields while newer CLIs can verify capabilities end to end.
+
+## 0.89.8
+
+### Daemon upgrades keep a recoverable service
+
+Background-service replacement now records the previous definition and native
+running state in an owner-only transaction receipt before changing launchd,
+systemd or Task Scheduler. A failed or interrupted replacement restores that
+service before another upgrade is attempted, and verifies whether it should be
+running or stopped.
+
+Native probe errors are not treated as proof that a service disappeared, and
+rollback preserves an administratively disabled service instead of enabling it.
+
+`pushary clean` now proves the background service was removed before changing
+agent configuration or local state. If removal cannot be proven, clean stops
+with the existing installation intact so it can be repaired and retried.
+
+## 0.89.7
+
+### clean no longer uninstalls the macOS app along with the CLI
+
+`clean` removed `~/.pushary` whole. That directory is not only the CLI's: the Mac
+app roots its entire runtime there, so the locator every hook execs, the socket
+the app listens on, its gate state and its spool all went with it. It also
+stripped the app's hook entries out of the agent configs. The app went on
+running and went on reporting itself connected, while nothing reached it.
+
+It now removes what the CLI owns and leaves `bin`, `run`, `spool` and `plugins`.
+Hook entries are attributed by the command they name, so the app keeps its own.
+`disconnect` is unchanged and still disconnects an agent whichever product
+connected it.
+
+The `mcpServers.pushary` entry and the VS Code plugin directory cannot be
+attributed to either product, so they are kept when the app is installed and
+removed when it is not. A CLI-only clean still leaves no API key on disk.
+
+### clean handles OpenCode
+
+setup installs an OpenCode plugin and an MCP entry and `clean` walked past both,
+so a command that says it removes all Pushary configuration left the sixth agent
+wired. A `pushary.js` somebody else wrote, or one the Mac app wrote, is left
+alone.
+
+## 0.89.3
+
+### Doctor recognizes hooks installed by the macOS app
+
+Claude Code, Codex and Gemini hooks that point at the shared native
+`pushary-bridge` now pass the same presence, executable and timeout checks as
+their npm hook binaries. Doctor no longer tells a Mac-managed install to repair
+hooks that are already installed and running.
+
+## 0.89.2
+
+### Multi-question prompts keep their real answer shape
+
+Claude still sends each question separately so older clients can answer it, but
+each card now carries its canonical metadata too. Current notch, phone, web and
+Slack surfaces keep descriptions, write-in answers and every multi-select value
+instead of collapsing a multi-select to one top-level option.
+
+## 0.89.0
+
+### Hermes approvals go to the phone, and setup wires it
+
+`setup --agents hermes` now selects Pushary as the Hermes approval transport,
+with `transport_fallback: builtin`. Hermes owns the timeout (300s) and the
+once/session/always/deny choices, and persists the last two, so a repeated
+approval can become a standing rule instead of being asked forever. The
+fallback is what makes selecting it safe: a missing key, an unreachable
+Pushary, or no connected device falls back to the terminal prompt rather than
+blocking work.
+
+The note explaining why setup writes `~/.hermes/config.yaml` directly rather
+than running `hermes plugins enable` was half wrong. Current Hermes does
+resolve pip-installed plugins in both `list` and `enable`; the reason to write
+the file is the rule against executing an agent's binary, and nothing else.
+
+### `pushary upgrade` named a package that does not exist
+
+It printed `pip install --upgrade pushary-hermes`. That package is not on PyPI.
+The real one is `hermes-plugin-pushary`, and the upgrade path for it is setup,
+which installs into the interpreter Hermes actually runs in. Now points there,
+like every other agent in that list.
+
+## 0.88.1
+
+### One install, whichever surface writes it
+
+The generated hook spec now describes the whole install, not only the hooks: the
+MCP entry for each agent, the managed block in AGENTS.md or GEMINI.md, and the
+skill. The CLI writes exactly what it wrote before. The Mac app reads the same
+spec, so an install from the app and an install from `pushary setup` leave the
+same files behind, and Repair can put back a tool entry as well as a hook.
+
+`Elicitation` is no longer CLI-only in the spec: a typed answer can now come back
+from a settlement, so the Mac app writes that hook too.
+
+### One predicate for Ctrl-C at a prompt
+
+Setup carried its own test for an inquirer cancellation and matched a different
+string from the one in `cli/exit.ts`. Both agreed on inquirer's current wording
+and would have disagreed the day it changed, printing "Setup failed" over a
+deliberate Ctrl-C. One predicate now, matching the union of what both matched.
+
+## 0.87.1
+
+### Unanswered approvals hand off once and fail closed
+
+The installed agent instructions now distinguish a live timeout from cancelled,
+missing and unavailable questions. They poll once, cancel before moving the
+decision into the current client, reconcile the cancellation race once, and stop
+when Pushary cannot safely fence the question state.
+
+## 0.86.0
+
+### Approving a plan from your phone
+
+Exiting plan mode blocked the terminal and pushed nothing, so an away user's agent
+sat waiting on the one approval that decides everything after it. `ExitPlanMode` was
+never in the hook's tool matcher, and `plan` is a mode Pushary steps aside for
+entirely, so matching it alone would not have helped either.
+
+The plan approval now reaches your phone before Pushary steps aside, and it carries
+the plan itself, redacted and capped like any diff, so you are approving something
+you can read rather than a bare tool name. Two options rather than the terminal's
+three: a hook cannot set the permission mode the session lands in, so offering that
+choice would have quietly dropped half of what you picked.
+
+Falls back to the terminal exactly as before whenever the phone cannot answer.
+
+## 0.85.2
+
+### One agent-protocol renderer for CLI and native approvals
+
+Claude Code, Codex and Gemini hook output now comes from the shared contracts
+renderer also used by the native Mac gate. This keeps the CLI wire bytes unchanged
+while preventing the native bridge and published hooks from drifting into different
+allow or deny shapes.
+
+## 0.85.1
+
+### A rule you wrote is now honoured in auto mode
+
+A policy set to deny a tool outright was computed and then discarded in the three
+Claude Code permission modes Pushary steps aside for: `auto`, `plan` and `dontAsk`.
+`auto` is the default on Pro, Max and Team, so this was most sessions. The native
+classifier has never heard of your rule, so it would approve what you had forbidden.
+
+The defer exists to stop Pushary double-prompting on top of Claude Code's own
+prompt. A deny prompts nobody, so that reasoning never covered it. A standing deny
+now sits with the kill switch, ahead of the defer, and applies in every mode.
+
+Approvals are unchanged: `auto` still defers them, and a tool the classifier
+decides to ask about is still reclaimed through `PermissionRequest` and pushed to
+your phone. This only closes the case where a rule of yours was silently dropped.
+
+The Codex, Gemini and SDK wrapper paths already behaved this way. This brings the
+Claude Code path in line with them.
+
+## 0.85.0
+
+### A hook command that cannot outlive what it points at
+
+Every hook command written into `~/.claude/settings.json`, `~/.codex/hooks.json`
+and `~/.gemini/settings.json`, the free bell included, is now wrapped so that a missing binary, a removed
+`node`, a changed npm prefix or a moved home directory exits 0 and the agent reads
+"no opinion". Before, any of those turned every tool call into a failing hook.
+The guard is tested on every shell that can be `/bin/sh`, including dash, and with
+`node` off PATH, which used to exit 127 and print on every tool call.
+
+Codex hashes the exact command string to trust a hook, so `pushary upgrade` rewrites
+the trust entry when it re-applies the hooks.
+
+### Hooks registered for the CLI you have
+
+Claude Code events are registered from a table with a version floor per event.
+`SubagentStart`, `SubagentStop`, `PreCompact`, `PostCompact` and `TeammateIdle`
+are added on a CLI that understands them, and `pushary upgrade` re-registers
+against the CLI you have now. Disconnect removes every event in the table; a
+hand-typed list used to leave the five observability events behind.
+
+### `pushary disconnect <agent>`
+
+Removes the MCP server, the hooks, the skill and, for Codex, the trust entries and
+the API key from `config.toml`, for one agent, leaving the others alone. The bin
+map entry was written in a shape the build silently dropped, and the command read
+the dispatcher's own token as the agent name; both are fixed before this, its
+first release, and a test now holds every bin entry to the one shape tsup builds.
+
+### A kill switch per hook path
+
+`~/.pushary/admission-rules.json` (`{"version":1,"disabled":["claude:PostToolUse"]}`)
+silences one event on one agent, or one agent entirely, without a release. Every
+hook binary reads its input through this check, from the same file the macOS
+helper reads, so one file governs both transports. Deny-only: nothing in the file
+can enable a hook.
+
+### `PostToolUse` no longer pays two round trips per tool call
+
+The telemetry hooks reuse the mode state the gate fetched for the same session
+within the last 60 seconds. The gate itself still reads it live, so a remote stop
+and a scope contract are never served stale where they decide anything.
+
+## 0.84.1
+
+### Remote starts survive lost acknowledgements without double-launching
+
+A phone-started agent now claims exclusive process ownership before the provider
+starts. If the daemon restarts or the launch acknowledgement is lost, retrying the
+same request reconnects to the existing process instead of starting a second one.
+
+### Repository approval scopes reach Codex and Gemini
+
+Codex and Gemini sessions now carry their repository identity through approval
+requests, so repository-scoped rules stay inside the repository that created them.
+
+### Encrypted transcripts retry safely
+
+Transcript writers now retry while a session key is temporarily unavailable and
+stop on a real key conflict, preventing undecryptable transcript entries from being
+accepted or silently dropped.
+
+## 0.84.0
+
+### The phone can start an agent on a machine that is not running one
+
+The phone could reach a session that already existed. Starting one meant being at
+the keyboard. `pushary setup` and `pushary claude` now bring up a small background
+process, `pushary-daemon`, which watches for a launch requested from the phone and
+starts a real session with the prompt you sent.
+
+It is a poller over a durable queue, not an open socket. Idle, it asks the server
+for work every 30 seconds and sends one heartbeat a minute, and it carries a
+prompt, never any code. One request is in flight at a time, each bounded by its
+own timeout, with a spawn rate cap so a queue backlog cannot fill a machine with
+agents. Exactly one daemon runs per machine: a second one asks the first to hand
+over rather than racing it, and it declines to take over from a daemon that is
+still healthy.
+
+This is a background process that was not running before. `pushary doctor` reports
+whether it is up, and `pushary daemon` in a terminal shows you what it is doing.
+
+A launch is now acknowledged rather than assumed. The daemon claims a request,
+confirms the session it started, and the phone shows what actually happened,
+including the failure when a launch does not come up.
+
+### Always allowing a tool no longer has to mean everywhere
+
+"Approve and always allow" wrote one kind of rule: this tool, this whole
+workspace, until you delete it. That is the right scope for `Read` and far too
+wide for a push.
+
+The approval now offers the scope alongside it. Workspace is the previous
+behaviour. Repository binds the rule to the repository the ask came from, so a
+rule written in one checkout stops governing another. Session binds it to the run
+you are watching and goes away with it.
+
+An older Pushary never sees the narrower rules. A CLI that does not ask for them
+is sent workspace-wide rules only, so a rule you scoped to one session cannot be
+quietly applied everywhere by something released before the idea existed.
+
+### AskUserQuestion reaches the phone with its descriptions
+
+A Claude Code question carries a header, a description per option, and sometimes
+permission to pick more than one. The phone received the bare labels. It now
+receives the question the way the agent wrote it.
+
+One question goes out as one card carrying the whole shape. Every surface that
+does not know that shape, the web decision page and Slack among them, still sees
+an ordinary choice list and answers with a label, which the server reads back onto
+the question. Two or more questions go out one at a time, which is what every
+surface has always been able to answer: a bare label cannot say which of several
+questions it belongs to, and a half-filled answer is worse for the agent than
+being asked again in the terminal.
+
+### Codex and Gemini sessions started from the phone stay live
+
+A phone-started Codex or Gemini run now goes through a bridge that survives the
+connection dropping and resumes the same session instead of opening a new one.
+The machine advertises only what it can actually do, so a Gemini CLI too old for
+the bridge is not offered as one, and the phone stops showing controls that would
+fail.
+
+Stopping is acknowledged the same way. A stop request names the session and the
+process it belongs to, and the machine proves it owns that process before acting
+on it, so a recycled pid cannot be mistaken for the agent you asked to stop.
+
+
+## 0.83.0 to 0.83.2
+
+Three releases went out without an entry here. In order: `ask_user` became
+idempotent, so a create that gets retried after a timeout resolves to the question
+already asked instead of buzzing a phone twice. The pairing QR stopped encoding a
+code only a browser could resolve. And the gate's two shared pieces, the verdict a
+policy produces and the "most specific rule wins" precedence, moved into the
+package the CLI and the server both read, with no change to what either decides.
+
+## 0.82.0
+
+### Setup reads properly when an agent is the one running it
+
+An agent that runs `setup` relays its output to you, and two things in
+that output were written for a terminal that was not there.
+
+Colour was unconditional. Piped into an agent's transcript, ten raw
+escape sequences arrived as literal text around the parts you needed to
+read. Colour now follows the same rule the rest of the CLI already used,
+so it is on at a terminal and off everywhere else.
+
+The app download was unreachable until you gave up. "No app?" was
+answered with the command for approving in a browser, which sends you
+away from the phone at the moment you were being asked to install it,
+and the download link appeared only after the fifteen minute wait
+expired. The header now names https://pushary.com/download first and
+says the wait continues while you install.
+
+### The pairing QR is smaller
+
+The QR encodes a link, and the link's length decides the QR's size. It
+carried the pairing id and the public key, 114 characters, which drew 22
+rows of blocks. Against a server that offers one, the CLI now uses a
+short link instead: 33 characters, 16 rows, and small enough to survive
+being relayed through something that truncates.
+
+Nothing depends on it. Against an older server, or if the short link
+cannot be issued, setup uses the long one exactly as before, and the
+`pushary://` link is never shortened at all.
+
+
+## 0.81.0
+
+### The idle ping now honours a Terminal mode set in the dashboard
+
+"Your agent is waiting" pushes checked your delivery mode by reading the
+temporary override only. Choosing Terminal in the dashboard or the app
+does not write an override, it writes a standing rule, so the check never
+fired and the ping buzzed a phone whose owner had asked not to be reached.
+
+The ping now declares itself a task update, which puts it behind the same
+server-side gate as everything else the agent sends unprompted. That gate
+sees the standing rule, the kill switch and a mute. It also means your
+updates dial governs idle pings: set updates to Off and they stop.
+
+## 0.80.1
+
+### The bell's heartbeat directory is private to you now
+
+`pushary bell` counts how many agents are live by keeping one empty file
+per session in the system temp directory. On macOS that is already a
+per-user directory, so this was fine. On Linux it is the shared `/tmp`,
+where it was not: the first user to create `pushary-bell` owned it, and
+every other user on the box got a permission error and silently counted
+zero agents. Anyone who could write to it could also inflate the count
+and trigger the upgrade line.
+
+The directory is now per uid and `0700`, the heartbeats inside it `0600`,
+and the sweep judges an entry with `lstat` so a planted symlink is dropped
+rather than followed. Nothing about the bell itself changes, and it still
+makes no network calls.
+
+## 0.80.0
+
+### A bell, free, for when you only need to know it finished
+
+`npx @pushary/agent-hooks@latest bell` makes a noise in your terminal and raises
+a desktop notification when Claude Code says an agent finished or is waiting on
+you. No account, no API key, no network call. Nothing leaves your machine, and
+`pushary bell --off` removes it without touching anything else.
+
+If you run one agent, that is genuinely all you need and we would rather you did
+not pay for more. Above three agents at once the bell says so, once a day, and
+then stops talking, because a bell cannot tell you which of them is asking and
+cannot reach you once you have walked away.
+
+If you got here from `claude config set --global preferrednotifchannel
+terminal_bell` and the `unknown option '--global'` error, the README now answers
+that directly.
+
+### Setup waits for you to tap, instead of trusting that a push went out
+
+Setup used to finish on a delivered notification. A notification that arrives
+and cannot be answered looks exactly the same at that point, and that is the
+most common way this quietly breaks: approvals keep arriving and keep going
+unanswered.
+
+So setup now sends a real question and waits for you to answer it, and only says
+`Setup complete, and proven.` once you have. If nothing comes back it tells you
+rather than congratulating you. It only does this when someone is actually
+there, which includes a pairing you just scanned, and never in CI. Pass
+`--verify push` for the old behaviour, or `--verify none` to skip the check.
+
+`pushary doctor --roundtrip` runs the same check and now says the same things
+about it.
+
+### Your agent works out when to reach you, without being told
+
+The bundled skill used to describe itself only in terms of what you might say to
+it: ping me on my phone, run this overnight. That only fires when you are there
+to say something. It now also describes the moments that are true of the work
+itself: about to do something irreversible, about to spend money or deploy,
+blocked on a decision that is not the agent's to make, or a long task finishing
+with nobody watching.
+
+Everything it matched before, it still matches. Re-run
+`npx @pushary/agent-hooks setup` to update the copy your agents already have.
+
+## 0.79.0
+
+### Your agent now says what kind of update it is sending, so you can route it
+
+Pushary can now send task updates somewhere different from questions: approvals
+can wait at your keyboard while completions still buzz your phone, or the other
+way round. That only works if the agent says which one it is sending.
+
+The instructions setup writes now tell your agent to pass a context type when a
+task finishes. Without it a completion looks like any other notification, and
+the setting you chose for task updates has nothing to act on.
+
+Nothing changes for questions and approvals, and nothing you have configured
+needs revisiting. Re-run `npx @pushary/agent-hooks setup` to update the
+instructions your agents already have.
+
+## 0.78.0
+
+### Your agent can ask you several things at once, and reach your phone for all of them
+
+An agent that stops to ask you something often asks more than one thing in the
+same breath. Until this release the hook only recognised a single question, so
+two or more meant nothing arrived on your phone at all and the whole exchange
+waited at the terminal. That is exactly the moment this product exists for.
+
+Up to four questions now come through in turn. The notification says which one
+you are on, "(2 of 3)", so the first does not look like the last.
+
+If any question goes unanswered, whether you deferred it, it timed out, or no
+device was reachable, the entire exchange goes back to the terminal, including
+anything you already answered. A partly filled answer sheet would leave your
+agent guessing at questions it never put to you, and being asked twice is better
+than being answered wrongly.
+
+The whole exchange shares one wait budget. Four questions do not cost four times
+the wait you agreed to.
+
+Questions that let you tick several options at once still go to the terminal.
+Those answers travel as a single piece of text and the packing is not something
+this release can verify, so it is left alone rather than guessed at.
+
+## 0.77.0
+
+### Stop ends the process
+
+Until this release Stop was a gate verdict. Every pending and new tool call was
+denied, which is the guarantee and has not changed, but the agent kept running,
+kept thinking and kept spending tokens. For someone who hits Stop because
+something is going wrong, "it can no longer act" and "it stopped" are different
+promises.
+
+- every session event reports its own pid, so the server can name the process
+- the daemon advertises a `stop` capability, which is how the server knows a
+  machine can act on one at all
+- the daemon applies stops from the drain with SIGTERM, and refuses to signal
+  its own pid, since killing itself would take every other session's stop too
+
+Two additive wire changes, both safe in either direction: `pid` on the event
+payload, which an older server ignores, and `stops` on the drain response, which
+an older daemon ignores.
+
+## 0.76.1
+
+### Actually closing the spawn argv injection
+
+0.76.0 shipped under the message "closing the spawn argv injection" and did not.
+It sanitised `model` and `cwd` but not `prompt`, and `prompt` is the field the
+daemon passes as the token immediately after `-p`, so a flag-shaped prompt was
+read back as a flag:
+
+    ['claude','--remote','-p','--permission-mode=dontAsk'] -> {permissionMode:'dontAsk'}
+
+`dontAsk` is a full-defer mode, so the gate stopped asking about every tool for
+that session.
+
+The server-side rejection landed in production first and is what actually
+protects users, 0.76.0 included, with no upgrade required. This release carries
+the defence in depth: `buildSpawnLaunch` returns null for a flag-shaped prompt,
+so a daemon never builds that argv even if the server is bypassed.
+
+## 0.76.0
+
+### A phone-supplied field could switch your approval gate off
+
+`pushary claude --remote` sessions started from the phone build their command
+line from fields the request supplies. The wrapper then read that command line
+back to learn what it had been asked to do, and it scanned every position without
+knowing which ones were a flag's **value** rather than a flag.
+
+So a prompt or a model of `--permission-mode=dontAsk` was read as a real
+permission mode. `dontAsk`, `plan` and `auto` all defer to the agent's own prompt
+unconditionally, which means the session stopped asking you for approvals
+entirely, and the decision log recorded a session that was never gated. A clean
+approval history that is not true is worse than a missing one.
+
+Flag values are now consumed with the flag that owns them, so nothing a request
+supplies can be mistaken for an instruction. A `--permission-mode` you passed
+yourself still works, in both the `--permission-mode plan` and
+`--permission-mode=plan` forms.
+
+The server that queues these sessions now also refuses flag-shaped model and
+working-directory values, so an out-of-date CLI is protected against those two.
+It cannot do the same for the prompt, which is free text you are entitled to
+start with a dash, so **updating is what closes this one properly.**
+
+Reaching it needed an authenticated session on your own account, spawning to your
+own machine, with the daemon running. It is not cross-tenant and not remote code
+execution. It matters most where the person spawning is not the person governed:
+Team approval routing, Partner, and any case where a phone session or API key has
+been compromised.
+
+## 0.75.0
+
+### An agent can now run the install
+
+Pasting "install pushary for me" into Claude Code, Codex or Cursor exited 3
+before doing anything:
+
+    ! No API key, and no terminal to sign in from.
+
+The agent runs setup with stdin and stdout piped, so `isTTY` is false, and app
+pairing sat behind the same check as browser login. That check was answering the
+wrong question. Pairing needs a person, not a terminal, and the agent shows its
+output to one, so a QR written to stdout is read just as well as a QR drawn on a
+terminal.
+
+Setup now pairs whenever it is not running in CI. It prints the QR, the tappable
+link and the fingerprint, and waits for the scan, so the whole install is one
+command with nothing to paste:
+
+    npx @pushary/agent-hooks@latest setup
+
+Browser login still requires a real terminal, because it opens a browser on the
+machine and waits for a redirect. CI still declines to pair, so no build hangs
+drawing a QR into a log nobody is watching.
+
+The bundled skill told agents to do the opposite: hand the user a signup link
+and wait for them to paste a key back. It now says to run setup and show the
+user the QR.
+
+The failure message above also had to change, because after this it was naming a
+cause that no longer applies. Reaching that branch now means CI, `--skip-phone`,
+or a connect mode other than `app`, so setup says which of those it hit instead
+of blaming a missing terminal. A headless run with no flags is the one worth
+calling out: it used to be told to drop into a browser login it cannot open.
+
+
+## 0.74.0
+
+### The terminal went quiet while your phone was deciding
+
+A gated tool call sent the push and then blocked, writing nothing. Claude Code
+showed a bare spinner. If you missed the notification there was no way to tell
+that a question existed, let alone where to answer it, and the terminal prompt
+only appeared once the wait expired.
+
+The hook now says so before it blocks:
+
+    [pushary] Sent to your phone. Waiting 10s, then this terminal takes over.
+              Answer here instead: https://pushary.com/dashboard/agent
+
+The wait line prints per question, because each question is its own blocking
+moment with its own countdown. The URL prints once per session, because it is
+the same page every time and repeating it on every gated call is noise.
+
+That URL is the signed-in dashboard, not the `/decide` link the push carries.
+The decide link is a bearer credential: anyone holding it can answer. Handing it
+to the agent that is being gated would let it approve its own action, so the
+hook is only ever told about the page that requires your login.
+
+Servers that predate this send no URL, and the hook just prints the wait line.
+
+## 0.73.0
+
+### Codex could finish setup with no skill installed
+
+If your machine already uses skills.sh, setup installs the Pushary skill
+through that CLI so the install registers rather than being invisible. For
+Codex, `skills add --agent codex` prints "copy to Codex", says "Installation
+complete" and exits 0, then writes only `~/.agents/skills/pushary`. Nothing
+lands in `~/.codex/skills`, which is where Codex reads. Setup took the exit
+code as proof, skipped the copy it ships, and Codex ended up with no skill.
+
+Doctor caught it, and then gave advice that could not work: clean and set up
+again reinstalled exactly the same way and failed the same check.
+
+The exit code no longer decides this. What decides it is whether the run left
+a SKILL.md where that agent reads, which is the same thing doctor looks at,
+and setup writes its own copy when it did not. Anything skills.sh really did
+install is left exactly as it installed it, symlinks included.
+
+Everything else about the wiring was fine, so this cost you the skill and
+nothing more. Approvals, hooks and the instructions in `~/.codex/AGENTS.md`
+were all in place.
+
+### A skill that will not install no longer stops setup
+
+The skill is the one piece of the wiring nothing else depends on. It used to
+be able to abort setup partway, leaving an agent half configured. Now it warns
+and setup finishes the rest, and `pushary doctor` tells you the skill is
+missing.
+
+## 0.72.0
+
+### Setup tells you when Codex was already quarantined
+
+0.71.0 stopped setup from getting your Codex binary deleted. This handles the
+machines where it already happened. What macOS leaves behind passes every check
+setup made: the `codex` on your PATH is a small JavaScript launcher and it
+survives, `which codex` still answers, only the binary it launches is gone. So
+setup wired up an agent that could not start and reported success.
+
+It now says so before writing anything, and only when it can prove it: a vendor
+directory that exists and holds nothing the size of a native binary. A layout it
+does not recognise stays quiet, because telling somebody their working install is
+broken is the worse mistake. Reinstall with `npm install -g @openai/codex` or
+`brew install --cask codex`.
+
+### Setup no longer runs the Hermes binary either
+
+The same hazard, one agent over. When the config edit that enables the plugin
+failed, setup fell back to running `hermes plugins enable pushary` — executing a
+third-party agent binary, which is exactly what cost people their Codex install.
+The fallback also did not work, because `hermes plugins enable` does not see a
+pip install. It is gone, and a failed config edit now tells you the one line to
+add by hand.
+
+Executing an agent binary is now a build failure rather than a habit: every
+source file in this package is scanned on every CI run, and the check knows the
+difference between running `codex` and asking `which` where it is.
+
+## 0.71.0
+
+### Setting up Codex no longer gets Codex deleted by macOS
+
+Setup ran `codex --version` to decide whether your Codex was new enough for
+native hooks. On macOS, executing a binary hands it to XProtect, and current
+definitions false-positive on the Codex CLI: macOS killed it and moved it to the
+Trash. Reading a version number destroyed the tool it was asking, mid-setup, and
+the only thing you saw was "codex was not opened because it contains malware".
+
+Setup no longer runs Codex, or any other agent's binary, to learn something about
+it. The version now comes from the package manifest next to the binary, which
+covers npm, bun, pnpm and yarn installs, and from `brew list` for the Homebrew
+cask, which ships no manifest. Same result, nothing launched.
+
+## 0.70.0
+
+### A key you name is the key you get
+
+Passing `--key` with a malformed value did not fail. Setup read it as no key at
+all, went looking elsewhere, and used whichever key it found: one already stored
+on the machine, one in your environment, or a brand new one it created by pairing.
+You named a credential and quietly got a different one. It now stops and says the
+key is not valid.
+
+### setup --json no longer stops to ask a question nobody can see
+
+Asking for machine-readable output says plainly that no human is watching, but
+setup could still reach an agent-selection prompt. Piped into a script it waited
+for a keypress that was never coming, and the prompt drew itself onto the same
+output a program was trying to read as JSON. It now selects the agents it detects,
+which is exactly what pressing Enter on that prompt would have chosen.
+
+`--json` also promises a single object of output, and every failing exit used to
+print nothing at all. A refused key, a cancelled pairing and a crash were
+indistinguishable to anything reading the output. Each now says which it was.
+
+### Setup checks its own work
+
+An agent installer that finished without an error was reported as configured,
+even if nothing had been written. Doctor would then contradict setup minutes
+later. Setup now confirms the configuration is really there, using the same check
+doctor uses, so the two cannot disagree.
+
+### connect points at the fix that matches your situation
+
+`pushary connect --app` gave one answer for every way a phone can be out of
+reach: open the app and allow notifications. That is right when the app is signed
+in and the permission was declined, and wrong otherwise. A terminal that was
+never paired needs setup. A phone signed in to a colleague's account needs your
+account, not a permission toggle. It now says which applies, and when it cannot
+tell the two apart it says both rather than sounding certain about the wrong one.
+
+### The editor gates say when a proxy is in the way
+
+The Cursor and VS Code gates cannot route through a corporate proxy. They still
+hand the decision safely to the editor's own prompt, so nothing is blocked, but
+every approval quietly stopped reaching your phone with no explanation. When a
+proxy is configured they now name it as the likely cause, and on Node 24 or newer
+they name the setting that fixes it.
+
+VS Code is also now listed among the supported agents, which it has been since
+its plugin shipped.
+
+## 0.69.0
+
+### An approval is never granted on a state Pushary could not confirm
+
+When the hook could not reach Pushary, it read that as "you have not been
+stopped, and you are under no agreed scope". Those are answers, and not reaching
+the server is not an answer. A rule you had set to approve automatically could
+therefore fire during an outage on exactly the kind of call a live scope would
+have held back.
+
+It now tells the two apart. If the last successful check was under a minute ago,
+that answer still stands, so a brief network blip changes nothing, and a stop you
+issued moments earlier still stops the agent. Past that, an automatic approval is
+withheld and the decision goes to your agent's own prompt instead. Read only
+shell commands are unaffected, because that list is decided on your machine and
+needs no server at all.
+
+A rejected key is treated as a real answer rather than a blip, so a key you
+revoked stops being honoured at once.
+
+### A scope you agreed to is now honoured everywhere, not just in one place
+
+Scope was checked when Claude Code asked before running a tool, and skipped on
+four other paths that could reach the same decision: Claude's permission dialog,
+Codex, Gemini CLI, and the remote wrapper. Each of them fetched the scope you had
+agreed to and then ignored it, so the same edit could be waved through depending
+only on which route it arrived by. All five now run the same check in the same
+order.
+
+### Codex patches are judged on every file they touch
+
+A Codex patch that changes several files at once was judged on the patch as a
+whole, so a rule you wrote for one file did not apply when that file was part of
+a larger change. Every file is looked at now, and the strictest rule wins. Rules
+written as paths also work for Codex and Gemini, which they quietly did not
+before.
+
+### Command details that could contain a secret no longer leave your machine
+
+A command like `GH_TOKEN=... gh pr create` carries its credential in the first
+few words, and those words were being sent and stored as the label for what the
+agent wanted to do. Notification text was not being cleaned at all. Both are
+cleaned now, on your machine and again on arrival, and the Cursor and VS Code
+gates clean the command before it is sent rather than after.
+
+### setup --dry-run really does change nothing
+
+On a machine with no key, a dry run reached the pairing step, drew a QR code,
+waited for your phone, created a real API key, and then said nothing had been
+written. It now stops before anything is created and tells you a real run would
+connect a key first.
+
+### clean can no longer leave Cursor blocking your commands
+
+Cursor is told to block a matched command if the Pushary gate cannot answer, and
+that list includes ordinary work like rebase, migrate, deploy and publish. Clean
+removed the gate's files before removing that instruction, so if the second step
+failed, Cursor was left blocking all of them on a file that no longer existed,
+under a message saying clean had finished. The order is reversed and checked, and
+if the instruction cannot be removed the files stay put, clean says so, and it
+exits with an error.
+
+### Pairing survives a dropped reply
+
+If the reply carrying your key was lost in transit, the terminal reported that
+pairing had expired and you started again, while the key it never received stayed
+on your account. The key is now held until your terminal confirms it has it, so
+retrying finishes the pairing you already started. A terminal that cannot reach
+Pushary at all now says so instead of sitting under a QR code for fifteen
+minutes.
+
+### doctor reports on the agents you actually use
+
+Doctor checked Claude Code whether or not you had it, so setting Pushary up for
+Codex alone produced a column of failures about software you had never installed.
+It now reports on the agents Pushary is set up for, and says plainly when it is
+set up for none.
+
+Three things it used to call healthy, it no longer does. A key that lives only in
+a shell profile cannot be read by any hook, so an install where nothing could
+work was passing every check. A key saved inside Claude, Cursor or VS Code that
+no longer matches the one in use, which happens whenever pairing issues a new
+one, went unmentioned. And when doctor could not reach Pushary at all, it said
+everything was fine.
+
+Its exit codes now distinguish a broken setup from having no phone connected from
+not being able to reach Pushary, so a script can tell what went wrong. A test
+question nobody answers is now withdrawn instead of sitting on your phone.
+
+## 0.67.0
+
+### The VS Code agent can now ask for approval on your phone
+
+Setup has a VS Code option. It installs a Pushary agent plugin, connects the MCP
+tools so the agent can notify you and ask you questions, and registers a
+permission gate so a risky terminal command reaches your phone before it runs.
+The policy behind it is the one your other agents already use, so a rule you
+wrote for Claude Code applies here too.
+
+Two things about VS Code shaped how this works.
+
+VS Code reads a hook's matcher but does not act on it, so the gate is called for
+every tool the agent uses, including reading a file. It therefore decides for
+itself, and for anything that is not a risky shell command it returns straight
+away without touching the disk or the network.
+
+And a plugin folder does nothing until VS Code is told where it is. Setup adds
+that entry to your settings.json. That file usually has comments in it, and
+rewriting it as plain JSON would delete every one of them, so an existing file
+is edited one line at a time and left otherwise byte for byte identical. If your
+settings already have a plugin list with comments around it, setup does not
+guess: it prints the single line to paste and names the file.
+
+Unlike Cursor, VS Code hooks cannot ask the editor to block a command on the
+plugin's behalf. So when Pushary cannot reach you, or cannot reach its own
+server, the gate hands the decision to VS Code's own approval prompt rather than
+letting the command through.
+
+`pushary clean` removes all of it again, the settings.json entry included, and
+`pushary doctor` checks the three things that can be silently wrong: whether the
+plugin is registered at all, whether the gate script resolves, and whether your
+key is linked.
+
+## 0.66.0
+
+### Setup waited three minutes for a step that takes longer than three minutes
+
+If you already had the app installed and signed in, pairing resolved in seconds
+and this never came up. If you did not, it could not work at all.
+
+Scanning the QR without the app opens a page that sends you to the store. Install
+it, sign in, subscribe, come back, scan: that is never three minutes. The CLI had
+given up and cancelled the pairing long before, so a first-time user's first scan
+was guaranteed to fail, and the only route through was to notice the terminal had
+stopped waiting and run setup again.
+
+Setup now waits as long as the code is actually valid, and after the first
+45 seconds the spinner says what to do if the app is not installed yet. Ctrl-C
+still exits cleanly and cancels the pairing, so nothing holds you there.
+
+The window itself is unchanged in what protects it: a pairing id is 128 bits,
+single use, deleted the moment it is claimed, and authorising one requires a
+signed-in session for the owning account and the public key you physically
+scanned.
+
+## 0.65.0
+
+### The pairing QR now works when you scan it with your phone camera
+
+It did not. Scanning it opened the app on "Unmatched Route", and the only way
+through was the in-app scanner, which parses the QR itself and never routes.
+
+The QR encoded `https://pushary.com/app/pair`, and `/app/*` is claimed by the
+app: the AASA lists it and so does the Android manifest. The OS therefore handed
+the link to the app before the page could load, which was the intent. What it
+handed over was the path `/app/pair`, and the app's pairing screen is `/pair`.
+Nothing matched, on every build ever shipped.
+
+The QR points at `/pair` now. Nothing claims it, so the browser always opens it,
+and the page hands off to `pushary://pair`, which every shipped build already
+routes correctly. That is the whole reason for the move: the Android claim is
+compiled into the installed app, so no amount of server or app-store work fixes
+the phones already out there, and this does, today.
+
+`/app/pair` still serves the same page, so a link from an older CLI is not dead.
+
+## 0.64.4
+
+### The shell you ran setup in still exported the key it replaced
+
+0.64.3 stopped a stale export from hiding the working key on disk, and the rc
+file has been rewritten in place since 0.62. Neither reaches the shell you are
+standing in: the export there is still the old key, the environment wins over the
+config file at hook time, and the agent you start in that terminal a minute later
+talks to whichever workspace that key belongs to.
+
+`--connect app` mints on every run and is the command onboarding prints, so this
+is the ordinary case rather than an exotic one. Setup now says so under "Still to
+do": open a new terminal, or re-export. No key is printed in that line.
+
+## 0.64.3
+
+### A stale shell export hid the working key on disk
+
+`PUSHARY_API_KEY` wins over `~/.pushary/config.json`, which is right and
+unchanged. But the environment used to win on the key's *shape* alone, so a
+well-formed key the server had since revoked shadowed a working one in the config
+file and setup exited "This key was rejected by pushary.com" with a perfectly
+good key sitting on the machine.
+
+That is the state any shell left open across a key rotation is in: the export is
+the old key, the file is the new one, and the terminal you happen to be typing in
+decides whether setup works.
+
+The environment key is checked with the server before it is chosen now, and a
+rejected one falls through to the stored key rather than ending the run. It costs
+no extra call: the verdict is handed to the verification step that was already
+making it.
+
+### `--connect app` on a machine with no terminal named the wrong problem
+
+A headless run that asked to pair said "No API key, and no terminal to sign in
+from" even with a key in the config file, because asking to pair deliberately
+takes the stored key off the table. It now says the flag needs a terminal for the
+QR, and that dropping it uses the key already there.
+
+## 0.64.2
+
+### A run that gave up reported nothing, and said it stopped at the start
+
+`agent_setup_completed` was wired to one of setup's fifteen exits: the last line
+of a run that finished. Every other way out returned before it. A key the server
+refused, a cancelled pairing, no terminal to sign in from, an installer that
+threw, a Ctrl-C at the agent checkbox: all silent. The beacon was added so failed
+and abandoned runs would stop being invisible, and the runs it could see were
+still only the ones that already worked.
+
+Every early exit reports now, and each says why it stopped: `key-refused`,
+`pairing-cancelled`, `no-key`, `login-rejected`, `no-agents-detected`,
+`invalid-key`, `interrupted`, `crashed`.
+
+Argv-time exits stay silent, along with `--help` and `--dry-run`. A flag typo is
+not an abandoned run: nothing was attempted and nothing was written. It is also
+the fastest-failing path there is, and waiting on a beacon took `setup --bogus`
+from 60ms to two seconds against an unreachable server. A dry run stays silent
+for the other reason: counting it as a completed setup would be its own lie.
+
+`abandonedAt` said where. It was always `start`, because `markStep` had no call
+site outside its own test, so the field that was supposed to locate a failure was
+a constant. It now moves through the run, per agent inside the configure loop, so
+an installer that hangs is named rather than grouped.
+
+Ctrl-C at the pairing QR reports before the process leaves. The cancel and the
+beacon run concurrently and the exit waits for both, so this adds nothing to the
+worst case a cancel already had.
+
+The beacon authenticates with the key the run resolved rather than the one
+already installed. Most of these exits happen before the key is written to disk,
+so without that they posted as nobody, which meant the window holding the
+interesting failures was exactly the window that could not report.
+
+## 0.64.1
+
+### Ctrl-C at the pairing QR printed nothing
+
+The QR screen said "No app? Press Ctrl-C for the ways to finish without one", and
+pressing it printed nothing at all. `connectViaAppPairing` handles SIGINT by
+exiting the process itself, so control never returned to setup and the lines it
+meant to show were unreachable on the one path that advertised them.
+
+Setup now hands the escape to the pairing wait, which prints it inside the
+handler before exiting, and the line on screen names the command directly instead
+of telling you to interrupt the program to find out what it is.
+
+The same two commands are printed when a pairing simply never completes, so both
+ways out of the QR screen say the same thing.
+
+
+## 0.64.0
+
+### A typo on `--dry-run` ran a real clean
+
+`pushary clean --yes --dryrun`, one missing hyphen, silently dropped the flag it
+did not recognise and performed a full destructive clean: the stored key, the
+Cursor plugin, every agent config, and the global package itself. It printed
+"Clean complete." with the past tense throughout and exited `0`. The typo most
+worth catching was the one on the flag that means "change nothing", sitting next
+to the flag that means "do not ask me".
+
+`clean` now rejects a flag it does not know and exits `2` before removing
+anything. `--dry-run`, `--yes` and `-y` are unchanged.
+
+### Setup reuses the key this machine already has
+
+`setup` read `PUSHARY_API_KEY` and never `~/.pushary/config.json`, so the key
+`pushary login` had just written was invisible to it. `login` followed by `setup`
+in the same shell ran a second browser login and minted a second key, and a
+machine with no terminal that had been set up by `login` exited "no API key" with
+a working key sitting on disk. The shell export made it work in a *new* shell,
+which is what hid it.
+
+Setup now reads the stored key, verifies it, and uses it. A key the server no
+longer recognises falls through to a fresh sign-in rather than dead-ending, and a
+server it cannot reach keeps the key rather than discarding it.
+
+### The Pushary app is the default connect path
+
+An unflagged `setup` now pairs the app instead of sending you to the browser
+subscribe page. `--connect browser` is the fallback for a machine with no app,
+`--connect web` is the legacy page and keeps working exactly as before, and
+`--connect none` skips the phone step like `--skip-phone`. `auto` and `pwa` are
+accepted as input spellings.
+
+Pairing only happens when there is a terminal to show the QR to and no usable key
+already on the machine, so re-running setup to add an agent no longer asks you to
+scan anything, and no longer mints a key you did not ask for. Typing
+`--connect app` explicitly still pairs every time.
+
+When pairing does not complete, setup now names the two ways to finish without
+the app rather than only inviting you to try the QR again.
+
+
+## 0.63.2
+
+### Setup reports what happened, not only that it worked
+
+The setup event fired only when at least one agent had been configured, so a run
+that configured nothing, failed, or stopped partway reported nothing at all. The
+only visible runs were the ones that already worked.
+
+It now fires once per run whatever the outcome, and carries the connect mode and
+its result, how many agents failed, which were skipped, whether the run was
+non-interactive, and where a run stopped if it did.
+
+This is the same event that already powers your activity feed, sent with your own
+API key to your own workspace. No repo path, hostname or agent content is
+included, and nothing is sent before you have a key.
+
+
+## 0.63.1
+
+### `pushary status --bogus` printed a stack trace
+
+An unknown flag on `status` threw where nothing was catching it, so Node printed
+a raw stack trace and exited `1` instead of the clean usage error and exit `2`
+every other command gives. Other commands were unaffected.
+
+
+## 0.63.0
+
+### Machines
+
+`pushary daemon` now reports itself to your workspace once a minute, and
+`pushary status --devices` lists what is there:
+
+```
+  Machines
+  ● macbook-pro     0.63.0  just now
+  ○ build-server    0.62.6  4h ago
+```
+
+`online` is worked out from the last heartbeat rather than stored, so a laptop
+that closes mid-session reads offline a few minutes later without anything
+having to notice it left.
+
+This is what lets a phone start a session on a machine you name, instead of on
+whichever one happens to answer first.
+
+Presence is best effort throughout. A heartbeat that fails never stops the daemon
+draining its queue, and `status` still reports your key and channels if the
+machine list cannot be read. Against a server that predates the endpoint,
+`--devices` says so rather than reporting an empty list.
+
+**Needs a database migration** (`0066`). Until it is applied, `--devices` reports
+that it could not read the list, and nothing else is affected.
+
+
+## 0.62.6
+
+### `clean` rewrote your project's Cursor config and left your own alone
+
+`clean` built the Cursor MCP path without a home directory, so it resolved
+against whatever directory you ran it from. Inside a repo that has a
+`.cursor/mcp.json`, it rewrote that committed file, stripping the Pushary entry
+and reformatting the rest. Meanwhile your real `~/.cursor/mcp.json` was never
+touched, so the API key stayed in it.
+
+Check `git status` in any project you ran `clean` from, and check
+`~/.cursor/mcp.json` for a key you thought was gone.
+
+### Every file the CLI touches is now named in one place
+
+`setup`, `clean`, `doctor`, `logout` and `upgrade` each derived the same paths by
+hand, and they drifted. That drift caused this bug and the `CODEX_HOME` one
+before it. All twenty-three call sites now resolve through one module, and a test
+fails any command that starts spelling a path out again.
+
+No behaviour changed anywhere else: setup's output is byte-identical across every
+mode before and after.
+
+
+## 0.62.5
+
+### `clean --dry-run` changed things again
+
+0.62.4 moved the dry-run guards into their own module and passed the flag in by
+value. That happened at module load, before the flag had been parsed from the
+command line, so every guard was built in live mode and stayed there. A dry run
+stripped the Codex key, rewrote agent configs and removed the plugin directory,
+while printing "would" beside each one.
+
+The guards now read the flag when they run rather than when they are built, so
+there is no longer an order in which they can be created too early.
+
+If you ran `clean --dry-run` on 0.62.4, treat it as though you ran a real clean:
+re-run `setup` to reconfigure.
+
+
+## 0.62.4
+
+### `pushary clean` crashed partway through on Node 24
+
+`clean` threw `ERR_INVALID_ARG_TYPE: The "options.force" property must be of
+type boolean` and died mid-run, after cleaning some agents and before touching
+the rest. Introduced in 0.62.0 by the `--dry-run` work, which started passing
+`force: undefined` to `rmSync` on every call that omitted the option. Older Node
+ignored that; Node 24 rejects it.
+
+If a clean died on you, re-run it. It is safe to run repeatedly and picks up
+whatever is left.
+
+The three mutation primitives behind `--dry-run` now live in `src/cli/dry-run.ts`
+instead of inside the command file. Both `--dry-run` defects that reached users
+were in those few lines, and both got past tests that could only read the source
+as text, because code in `bin/` runs at import and cannot be called by a test.
+They are ordinary functions with ordinary tests now.
+
+### The authorize page's code input overflowed its card
+
+The eight character slots were a fixed width, so they added up to 488px inside a
+384px card and spilled out of both edges. They now share the row and shrink to
+fit, down to a 320px phone.
+
+
+## 0.62.3
+
+### `setup --connect app --key ...` discarded your key
+
+Pairing was checked before the supplied key, so passing `--key` or `--key-stdin`
+alongside `--connect app` silently threw that key away and minted a new one. The
+key you named stayed live on the account with nothing pointing at it. An
+explicitly supplied key now wins, and pairing is only the key source when there
+is no key to use.
+
+Pairing still mints a key each time it runs, which is inherent to the protocol.
+When that replaces a key this machine was already using, setup now says so and
+names the old key, rather than leaving you to find it in the dashboard later. It
+does not revoke it for you: the same key may be in use on another machine.
+
+### The update banner offered downgrades
+
+Setup compared its version to the registry with `!==`, so it announced an update
+whenever the two merely differed. A machine running a build ahead of npm was told
+`Update available: 0.62.3 -> 0.62.2` and pointed at a command that would have
+downgraded it. It now prompts only when the registry is genuinely ahead, using
+the same comparison `pushary upgrade` already used. There is one implementation
+of that comparison now instead of two.
+
+### A reused key skipped its own verification
+
+Setup skipped the server key check whenever `--connect app` was passed, on the
+assumption the key had just been minted. That is only true when pairing actually
+produced it, so a key reused on an `--connect app` run was never verified. The
+skip now follows where the key came from.
+
+
+## 0.62.2
+
+### An ignored `--dry-run` made real changes
+
+`mode`, `wait`, `suggestions` and `status` read their arguments positionally and
+silently discarded any flag they did not recognise. So `pushary mode push_only
+--dry-run` dropped the flag and changed the mode for real. Those four now reject
+an unknown flag and exit `2`, and they do it before looking for your API key, so
+a typo is reported as a typo rather than as a missing key.
+
+### The proxy support was never switched on
+
+`HTTP_PROXY` and `HTTPS_PROXY` handling was written but never called from
+anywhere, and Node's fetch ignores both without it. Behind a corporate proxy,
+setup verified your key through the one code path that used it, reported
+everything healthy, and every approval afterwards failed. It is now installed by
+the shared HTTP layer, the MCP transport and the command dispatcher.
+
+### `doctor --json` woke your phone on every run
+
+The test push was skipped only for `--no-push`. Running `pushary doctor --json`
+on a schedule sent a real notification each time. It is now opt-out for a person
+at a terminal and off by default for `--json` or a non-TTY. Pass `--roundtrip` to
+send one deliberately.
+
+### Browser login could stall on the plan step
+
+Choosing a plan navigated the same tab away from the authorize page, and that
+page was the only thing that could finish the login once the plan activated, so
+the terminal waited on a promise nothing was going to keep. Checkout now opens in
+a new tab and the page completes the login by itself. The CLI no longer claims it
+finishes on its own without saying the tab has to stay open.
+
+
+## 0.62.1
+
+### `pushary clean --dry-run` was not a dry run
+
+In 0.62.0 the flag ran four real operations while printing "would":
+
+- uninstalled the global `@pushary/agent-hooks` package
+- rewrote your shell profile to remove the `claude` alias
+- stripped the Pushary block from `~/.codex/AGENTS.md`
+- stripped it from `~/.gemini/GEMINI.md`
+
+If you ran `pushary clean --dry-run` on 0.62.0 and the CLI then seemed to
+disappear, that is why. Reinstall with `npm i -g @pushary/agent-hooks`, and check
+your shell profile and those two files against version control if you keep them
+there.
+
+### `pushary upgrade` could destroy `~/.claude.json`
+
+`upgrade` treated an unparseable config as an empty one and wrote it back, so a
+truncated `~/.claude.json` was replaced with nothing but the Pushary MCP entry,
+losing every project, MCP server and permission rule in it. A half-written
+`~/.claude.json` is what an interrupted write leaves behind, so this needed only
+one earlier crash to line up.
+
+A config that cannot be parsed is now left untouched, and the other agent files
+are still refreshed around it.
+
+
+## 0.62.0
+
+### `pushary clean` could leave your API key on disk
+
+If `CODEX_HOME` was set, `clean` looked for Codex's `config.toml` in `~/.codex`
+and never found the real one. It printed `Codex config (not found)`, exited `0`,
+and left the key in the file. A user who ran `clean` to remove their key was told
+it had worked.
+
+The same fault ran through the rest of the Codex path. With `CODEX_HOME` set:
+
+- `setup` wrote the MCP server, the trust hashes and the notify entry to
+  `~/.codex/config.toml` while writing `hooks.json`, `AGENTS.md` and the skill to
+  the real `CODEX_HOME`, splitting the install across two directories
+- `setup --dry-run` named the relocated path, so the preview and the real run
+  disagreed about where the key would land
+- `doctor` read the relocated config and reported the key missing
+- `logout` treated an exported-but-empty `CODEX_HOME` as a path relative to the
+  current directory
+
+If you use `CODEX_HOME`, run `pushary clean --dry-run` to see what is still
+there, and check `$CODEX_HOME/config.toml` for a key you thought was gone.
+
+### New
+
+- `pushary clean --dry-run` lists everything it would remove and changes nothing
+- `pushary doctor --bundle` writes a redacted diagnostics file for a support
+  thread. Keys, your home directory and the machine name are stripped.
+- `pushary logout --revoke` kills the key server-side as well as locally, so it
+  stops working everywhere rather than only on this machine
+
+### Changed
+
+- `pushary upgrade` now refreshes Codex, Gemini CLI and Cursor, not only Claude
+  Code, and names the agents it actually touched. It matters most for Codex,
+  whose hooks are trusted by hash: a refreshed hook command without a refreshed
+  trust entry is a hook Codex silently declines to run.
+- `pushary upgrade` with no global install now names the install modes it can
+  see and the command that updates each, instead of one generic line and exit 0
+- `pushary daemon` stops on a rejected key or a closed plan and exits `4`
+  (`UNAUTHENTICATED`). It used to treat that like a network blip, back off to a
+  two-minute poll and sit there under an `online` banner, so a revoked key left a
+  daemon that looked healthy and would never launch anything again.
+- Ctrl-C during app pairing now cancels the pairing on the server, so a QR still
+  on your screen stops being claimable immediately instead of staying live for
+  the rest of its five minutes
+- `setup` prints the command surface when it finishes
+
+## 0.61.0
+
+The largest release since the CLI shipped. Setup no longer asks you to paste an
+API key, the key is checked against the server before anything is written to your
+machine, and commands exit with codes that mean something.
+
+### Read this first: exit codes changed
+
+Commands that used to print a failure and exit `0` now exit non-zero. If you run
+any of these in CI or chained behind `&&`, this is the part that affects you.
+
+| Command | Was | Now |
+| --- | --- | --- |
+| any unknown command or `pushary` typo | `0`, printed help | `2` |
+| `doctor` with a failing check | `0` | `5` |
+| `setup` with a revoked key | `0` | `4` |
+| `setup` with an expired or locked plan | `0` | `5` |
+| `mode`, `wait` with a rejected key | `0` | non-zero |
+| `status` with no key configured | did not exist | `3` |
+
+The full ladder: `0` ok, `1` failed, `2` usage, `3` not configured,
+`4` unauthenticated, `5` problems found, `6` no device, `7` input required,
+`8` unreachable, `130` interrupted.
+
+`pushary doctor && deploy` used to succeed against a machine doctor had just
+declared broken. That is the change worth knowing about.
+
+### Sign in instead of pasting a key
+
+`pushary setup` opens a browser, shows you a code, and receives the key sealed to
+a keypair generated on your machine. The key is never pasted, never shown in a
+terminal, and never transits in a form the server could read.
+
+- `pushary login` and `pushary logout` as standalone commands
+- Pasting a key still works, as a fallback and via `--key`
+- `--key-stdin` reads the key from stdin, so it stays out of your shell history
+  and out of the process list
+
+### New commands
+
+- `pushary status` reports what this machine is connected to, with `--json`
+- `pushary login`, `pushary logout`, `pushary connect`
+
+### Setup
+
+- The key is verified against the server before a single file is written. A
+  revoked key or a locked plan stops the run instead of producing a config that
+  looks finished and never delivers.
+- `--yes` runs setup with no prompts, for CI and images
+- `--agents claude_code,codex,...` picks agents without asking
+- `--dry-run` prints what it would do and touches nothing
+- Agent detection is real, so an agent you do not have is reported as skipped
+  rather than counted as configured
+- Ctrl-C in a trailing prompt no longer reports the whole run as failed
+- A stale `PUSHARY_API_KEY` export in your shell profile is now replaced rather
+  than skipped. It used to win forever over a newly rotated key.
+
+### Delivery is proved to your phone, not just to the workspace
+
+Setup and doctor now check that an approval reaches **you**, not merely that
+somebody in the workspace has a device. On a shared site where the only reachable
+channel cannot be attributed to you, that is said plainly rather than reported as
+success.
+
+### Diagnostics
+
+- `pushary doctor --json` for one machine-readable envelope
+- `pushary doctor --roundtrip` sends a real approval and waits for the tap. It
+  works without a TTY, where the old confirm prompt could not run at all.
+- `pushary doctor --no-push` for a check that stays silent
+- doctor reads the same key the hooks will actually use, honoring
+  `PUSHARY_CONFIG_FILE`, and reports a Claude or Cursor config holding a
+  different key
+
+### Correctness
+
+- `--help` and `--version` print and exit instead of running the command.
+  `pushary daemon --help` used to start a daemon; `pushary hook --help` used to
+  block forever on stdin.
+- Unknown flags are rejected on the commands that parse them, instead of being
+  coerced into a plausible wrong value. `--connect` with an unrecognized mode used
+  to silently mean `web`.
+- Every file this CLI writes is written atomically, so an interrupted setup can
+  no longer truncate a large `~/.claude.json`
+- An unparseable agent config is left alone instead of being overwritten
+- Files holding your key are created `0600`
+- `CODEX_HOME` is honored when locating `config.toml`
+- Hermes setup works on Windows
+- The Cursor plugin is staged and verified before the old one is replaced
+- `installGlobally` pins the exact running version instead of drifting to latest
+- `pushary clean` removes only the export line it wrote, not every line in your
+  shell profile that mentions the key variable
+- Requests honor `HTTP_PROXY` and `HTTPS_PROXY`
+- Color honors `NO_COLOR` and `FORCE_COLOR`, and turns itself off when output is
+  not a terminal
+- `--json` output is machine-readable on stdout, with human text on stderr, so a
+  pipe never receives a spinner
+
+### Pairing
+
+The pairing QR now points at a real web page, so scanning it on a phone without
+the app installed lands on install instructions for that platform instead of a
+dead custom-scheme link.
+
+### Known gaps
+
+- `status`, `clean`, `mode`, `wait`, `stats`, `suggestions` and `upgrade` still
+  ignore an unknown flag rather than exiting `2`. Unchanged from 0.60.0.
+- `pushary upgrade` reapplies Claude settings only. Other agents need `setup`.
+- Codex hook trust still uses a fixed version ceiling, so a newer Codex is sent
+  to the manual `/hooks` step.