Pushary: answer Codex approvals from your phone, or send a git push to your team lead

[aadilghani1]

I build Pushary, a paid hosted service, so weigh this accordingly.

Pushary connects Codex through its native hooks and an MCP server. Before a shell command, an apply_patch edit or an MCP call runs, the hook checks your policy. A call that needs a person waits, and the question shows up on your phone, in the Mac app or in the dashboard. Your answer goes back to Codex.

npx pushary@latest setup --agents codex

• Hooks need Codex 0.122 or newer. On an older Codex, setup installs the notify handler instead, which only sends notifications.
• Codex runs a hook only after you trust it. Setup writes the trust entries. If it prints "One step left", run /hooks in Codex and trust the Pushary commands.
• It works with the Codex CLI and with Codex in the ChatGPT desktop app.

On a team, once a second person joins the workspace, an owner can add a routing rule such as Bash(git push:*) in the infra repository, routed to the Admins role. That push then asks the admins instead of the person running Codex, and the record shows whose agent asked and who answered. The same rule matches Claude Code, Cursor and Gemini CLI shell calls.

What it doesn't do:

• A routing rule doesn't lock the terminal. If nobody answers in time, the person running Codex can still approve at Codex's own prompt, and that yes isn't recorded.
• The phone can only deny risky steps such as a force push or rm -r. Approve those in the dashboard.

One person is $9.99 a month after a 3-day trial, with a card to start. Team is $59 a month for 5 people, plus $12 for each extra person.

Setup guide: https://pushary.com/docs/agents/guides/codex

[ryanroundhouse]

For a team evaluating this with Codex, I'd split the setup check into “a question reached the phone” and “the intended tool call was gated.”

Your integration-testing guide already covers retries and execution counts. A small Codex-specific acceptance matrix alongside it would help:

• Older Codex, notification-only setup: a delivered notification must not count as a successful approval-gating test.
• Current Codex, untrusted hook: classify the gating test as not ready, rather than passing because the MCP test question worked.
• Trusted PermissionRequest, terminal fallback selected, no remote answer: verify the call waits at Codex's own prompt. If someone approves there, label the decision local, not approval by the routed admin.
• Trusted, gated PreToolUse in When away, with a device connected and the user away: let the rule's timeout elapse and check refusal. Don't reuse the terminal-fallback expectation from the previous row.

Those last two expectations come from your Codex hook guide; keeping the event name in each result would make the difference easier to spot.

Use a harmless local test action explicitly covered by a test rule, and record Codex/Pushary versions, hook trust, event, mode, matched rule/timeout, decision source and actual execution outcome. That gives a team a small reproducible receipt before trying a real push.

I haven't installed or run Pushary; this is a docs-based test suggestion, not a failure report. Disclosure: I build Zozo HQ, a coding-agent harness. Written with AI assistance.

[aadilghani1]

Thanks, this is a fair split. Two of your rows found a real gap: setup ended on "You're set" once the test question was answered, even when Codex was older than 0.122 or wasn't running the Pushary hooks. That question only proves the phone path. From 1.9.112 setup says so instead, and that's tested against a real Codex binary. The Codex guide now has a short gating check for your four cases: https://pushary.com/docs/agents/guides/codex#check-that-a-call-is-gated-not-just-notified

On the third row: an answer typed at Codex's own prompt never reaches Pushary, so it isn't recorded as the approver's. Activity can show the step was left to the terminal, not who said yes.

[ryanroundhouse]

Thanks for the detailed follow-up and for adding those checks!

[Sadrak2017]

Could the team guide add a pending-request role-change case? Route a harmless test action to Admins, remove the recipient's role, then answer from the already delivered prompt. That distinguishes the routing snapshot from authority when the decision is accepted. In our Sinaps Studio work at SinapsData, tool permission is checked again at execution; I would want that timing explicit for the human side too. The audit can retain who was originally notified without presenting that as continuing authority.