Tools

codex

codex-cli at /Users/titus/.local/bin/codex, run non-interactively via codex exec. A genuinely independent model — which is what makes it worth the wall clock for a decision record or a plan.

Invocation — two flags are load-bearing

codex exec --sandbox read-only -o /tmp/codex-out.md "<prompt>" < /dev/null

• < /dev/null is mandatory. codex exec appends piped stdin to the prompt, so when stdin is an open pipe that never closes — exactly what a backgrounded agent shell gives it — codex prints Reading additional input from stdin... and blocks for ever. It looks identical to a model thinking hard: process alive, zero output, no error. Verified 2026-07-31, after two runs hung 20 minutes each doing nothing.
• -o <file> is how the answer survives. Without it the result exists only in buffered stdout and is lost entirely if the process is killed or times out.

Long reviews take many minutes. Run backgrounded, then poll the -o file — not the stdout file, which stays empty until the very end and tells you nothing.

Before blaming the model for being slow, check the output file for the stdin message, and confirm the pid you are watching is the run you started.

What to ask it

Give it the repository facts it needs to disagree — what exists, what does not, which module owns what — not just the plan. A reviewer that cannot check the premises can only agree.

Ask it to attack: is this justified now, is it in the right place, what does it miss, what is expensive to reverse. Ask for the strongest argument against.

Report what codex found and your own judgement on it. Its verdict is input, not a rubber stamp. Say plainly where you disagree and why — relaying its findings unfiltered is not review.

agent-browser

System-wide binary at /opt/homebrew/bin/agent-browser, for browser automation and screenshots.

agent-browser open <url>
agent-browser screenshot <path>
agent-browser snapshot            # accessibility tree
agent-browser close

Use it whenever a web page needs to be viewed or screenshotted. Never claim you do not have browser access.

ctx7 — current documentation

Fetch current documentation whenever the question is about a library, framework, SDK, API, CLI tool or cloud service — even well-known ones, and even when you think you know the answer. Training data does not reflect recent changes. Prefer this over web search for library documentation.

npx ctx7@latest library "<name>" "<what to look up>"   # → /org/project
npx ctx7@latest docs <libraryId> "<what to look up>"

• Use the official library name with proper punctuation — "Next.js", not "nextjs"; "Customer.io", not "customerio".
• Pick the match by exact name, description relevance, snippet count, source reputation and benchmark score.
• One concept per docs query. Combined multi-topic queries dilute ranking and return shallow results for each. Never more than 3 commands per question.
• Version-specific docs: /org/project/version from the library output.
• Never put credentials in a query.
• Do not use for: refactoring, writing scripts from scratch, debugging business logic, code review, or general programming concepts.

If a command fails with a DNS or network error inside a sandbox, rerun it outside the sandbox — retrying inside will fail identically. On a quota error, say so and suggest npx ctx7@latest login; do not silently fall back to training data.

git

Conventions for attribution, commit messages and when to push are on git conventions.