Docs

Setup

1. Create an account at app.reright.it.
2. Open the dashboard. It shows a setup block with a one-time code that is valid for ten minutes.
3. Paste the block into your agent. It fetches app.reright.it/setup.md and runs the installer. You can also run reright install yourself in a terminal.

The installer finds Claude Code, Codex CLI, Gemini CLI, GitHub Copilot (CLI and VS Code) and Cursor on your machine and configures every one it finds, at user level. For each agent it adds hooks that block unapproved sends, registers the MCP server and adds a rules text. Cursor keeps user rules in its settings, so the installer prints that text for you to paste. It also installs a git commit check, unless you pass --no-git.

The installer exchanges the code for a token that belongs to that device, downloads reright-hook and checks its checksum, and backs up each file before it changes it. It ends with a test submission that you approve in the browser. It writes only files in your home directory, never files in a repository, because an agent can edit those.

Run reright doctor to check each step. Run reright uninstall to put the files back. If you edited a file after the install, only reright's entries are removed and your edits stay. A code that was already used or has expired is refused, so ask the dashboard for a new one.

Using it

The MCP server has two tools.

• submit_for_review takes a kind, the text, a markdown context that helps you judge it, a target such as a repository and branch or a recipient, an agent and a run that group the queue, and optionally a diff and an origin. It returns an id and the review link.
• wait_for_review takes the id and blocks until you decide or the wait times out. It returns the status and, when approved, the final text.

The kinds are commit, pr, pr_comment, code_comment, odoo_log_note, odoo_message, email, chat and other. For commit, pr and email, the first line is the title or subject, then a blank line, then the body.

Reviewing

Open the link from the notification or the queue. Edit the text if you want to, then decide. The oldest pending draft is shown first, and after each decision the next one loads with focus in the editor.

Keys	Action
Ctrl+Enter	Approve
Ctrl+Shift+Enter	Reject, with the reason field focused
Esc	Back to the queue
Alt+Down and Alt+Up	Next and previous pending draft
?	Show the shortcuts

Notifications

On the dashboard, open Notifications and turn on push for each browser or phone you use. A push message names the kind of draft and its target. You can add the first line of the draft to push messages, which are encrypted for your device.

On an iPhone or iPad, push only works once reright is on the Home Screen. Open the app in Safari, tap Share, choose Add to Home Screen, open reright from its icon and turn on push there.

You can also enter an ntfy topic address. ntfy messages carry the kind, target and review link, never the draft text. If none of your devices has push turned on, we email you when a draft has waited more than 15 minutes. You can change the delay, or set it to 0 to turn the email off. The email never carries the draft text.

What you approve is exactly the text in the editor, character for character. If you reject, the agent is told to stop and wait for your instructions.

Connect other clients

The installer already sets up the five agents in the table below. For any other client that can call MCP tools, add reright as a remote MCP server. It works with any model provider, in the cloud or on your machine.

• Server URL: https://app.reright.it/mcp
• Sign in: OAuth 2.1, which most clients handle when you add the URL, or a device token that you create on the dashboard.

Each client has its own way to add an MCP server. Follow its own documentation, linked below, and give it the server URL.

"Built from its documentation" means we tested the hooks only against the payloads the tool's documentation describes, not against the real tool. We also do not know whether the hooks still run in each tool's no-approval or auto-run mode. "Connects over MCP" for other clients means their documentation describes remote MCP tool support, not that we have run reright there.

Rules text

The installer writes this text into each agent's rules file. For a client it did not set up, add the text to its instructions, its rules file or the system prompt of your assistant. It tells the agent to submit text first and to use only the approved version.

<!-- reright:start -->
## reright: approval for text people read

Every piece of text a person will read goes through reright before you use it: commit messages, PR and issue titles and bodies, PR comments, code comments, Odoo log notes and messages, emails and client messages. That includes drafts you would otherwise show the user in chat for approval. Apply the humanizer rules to your draft before you submit it.

1. Call `submit_for_review` (reright MCP server) with the kind, the exact text, the target, `agent`, `run` and a context block. For commit, pr and email, the first line is the title or subject, then a blank line, then the body. For a code comment, submit the comment text with kind `code_comment` and target `file:line` before writing it into the file.
   - `agent` is your short name or the tool you run in, such as `Claude Code`. `run` names the loop, job, session or subagent, such as `nightly-digest` or `fix-rounding`. The reviewer often has several of these waiting, and the queue groups by them, so use the same spelling every time.
   - Write `context` as markdown in plain language, with these short headings: `## What this is` (one line naming the text and where it goes), `## Why` (the reason, and the ticket or thread it answers), `## Who reads it` (the audience and what they already know), `## What changed or history` (the change in a few bullets, or the earlier messages). Leave out a heading that has nothing to say. The reviewer reads it beside the text to check the text against it.
2. Give the user the review link once, then call `wait_for_review` with the id until the status is no longer pending.
3. Approved: use `final_text` exactly, character for character. Do not reformat, rewrap or add to it.
4. Rejected: stop the task. Do not retry, rephrase or look for another way to send it. Tell the user it was rejected and wait for their instructions.

Hooks block `git commit`, `gh` PR and issue text, Gmail sends and browser `insertText` whose text reright has not approved. Where a skill says to show the user the exact text and wait for their go, reright approval is that go.
<!-- reright:end -->

A rules text is a request. An agent or client that ignores it can send unapproved text, and reright will not know. The next sections explain what the hooks do and what gets past them.

How the hooks work

reright-hook is a small program that Claude Code runs at three points. All three read the hook input from Claude Code on standard input. Codex CLI, Gemini CLI, Copilot and Cursor call the same program through their own hook systems, with an --agent flag, and it turns each tool's input into the same checks.

• pre runs before every tool call. It looks for outgoing text: the message of a git commit, the title and body of gh PR and issue commands, Gmail sends, drafts and replies, and text typed into the browser. It normalizes each text, hashes it with SHA-256 and asks the server whether that hash was approved in the last 24 hours. If not, the call is denied and Claude is told to submit the text for review.
• post runs after wait_for_review. If the result is a rejection, it writes a lock file for that session, and pre then denies every tool call in the session.
• prompt runs when you send a message to Claude. It removes the session lock, so a reject holds until you type something.

For commits, PRs and emails, the full text, the title alone and the body alone are all recorded on approval. That lets gh pr edit --title pass when the title is part of an approved draft.

The hook blocks a call when it cannot tell what would be sent, for example a command that builds the message from a variable it cannot resolve. It also blocks when it cannot reach the server. Two environment variables change that on your own machine: RERIGHT_OFFLINE=allow lets text through when the server is unreachable, and RERIGHT_BYPASS=1 skips the text checks. A reject lock still holds when bypass is on.

Enforcement and its limits

reright is a checkpoint for text, not a sandbox. Three layers check text, and each one has gaps.

Agent hooks

Claude Code, Codex CLI, Gemini CLI, GitHub Copilot and Cursor can run a hook before a tool call. The hook blocks git commits, GitHub CLI text, Gmail sends and text typed into the browser unless that exact text was approved.

• Claude Code is tested end to end. The other four are built from their documentation and tested only against the payloads it describes. We have not run them in the real tools.
• We do not know whether hooks still run in each tool's no-approval or auto-run mode: the Codex bypass flag, Gemini CLI --yolo, Copilot --allow-all-tools and Cursor auto-run. For Claude Code, --dangerously-skip-permissions has not been checked either.
• Copilot hooks may not fire for MCP tools, and a hook timeout in the Copilot CLI lets the call through. Codex asks you to trust new hooks, and they do nothing until you do. Cursor cloud agents do not support the MCP hook.
• The hooks run on your computer and you control them. Anyone with access to your settings can remove them, turn them off in the tool, or set RERIGHT_BYPASS=1. RERIGHT_OFFLINE=allow lets text through when the server is unreachable.
• The hooks only inspect the tool calls they understand. They read shell wrappers such as env, sudo and find -exec, and scripts that already exist on disk. They do not read code that builds a command at run time, aliases from your own git config, an HTTP request to some other service, or an MCP tool the hooks do not know about.
• The check compares hashes. It proves the text was approved, not that it goes to the target you had in mind when you approved it.

Git commit check

The installer adds a git hook that checks the exact commit message. It works for any agent that runs git commit, including one with no hook system. It covers commit text and nothing else. By default it applies to commits that look agent-driven: a known agent environment variable is set, or there is no terminal. A person committing in a terminal is not blocked.

• git commit --no-verify skips part of the check. A message given with -m or -F is still checked by a second hook, but a message written by an editor command is not.
• Plumbing commands such as git commit-tree and git fast-import run no hook. Commits made through an API, such as the GitHub web editor or gh api, never reach a local hook.
• An agent that can run a shell can change core.hooksPath, edit the wrapper scripts in ~/.config/reright/git-hooks/ or set RERIGHT_BYPASS=1.
• The agent markers for most tools are unverified, and an agent can unset them or run in a pseudo-terminal. A commit from an IDE has no terminal, so it can be blocked by mistake. You can set the mode in ~/.config/reright/git.json.
• Git trailers added by git commit -s change the text, so the hash no longer matches unless the approved text already has them.

Other MCP clients

Chat assistants and other clients get the MCP tools and the rules text, with no hook. The client decides whether to follow the rules, and nothing forces one that ignores them.

Unattended agents are not supported yet. The flow assumes someone is there to review.

Quota

Each submit_for_review call counts as one message in the current calendar month (UTC). Over quota, the call fails with an upgrade link and the reset date. Deciding on or waiting for drafts that already exist never counts and never fails. See the pricing table for the plans.

Billing

interpt sells the paid plans directly and sends the invoices. Stripe takes the payment and calculates tax at checkout. Prices are in US dollars. VAT and other taxes are added at checkout where they apply. The billing portal, opened from the dashboard, lets you change plan and cancel. An upgrade starts at once. A downgrade or a cancellation takes effect at the end of the period you paid for.

How long text is kept

Text is deleted from the live database at the retention you choose, and from every backup within 48 hours after that. The clock starts at your decision. A draft that nobody decides expires on the same schedule from the moment it was submitted. wait_for_review then returns the status expired with an instruction to submit the text again if it is still needed, and the draft leaves your queue.

• Free keeps text for 1 day. This is fixed.
• Starter, Pro and Unlimited keep text for 1 to 90 days. The default is 30. Change it under How long text is kept on the dashboard. Shortening it deletes older text at the next hourly purge.
• The approval window that lets a commit or email through is 24 hours and does not depend on retention.

If your plan drops to Free, text older than one day is deleted at the next hourly purge after the change. The dashboard asks you to confirm before you start a downgrade. Deleted text cannot be recovered. Backups only go back about a day, so point-in-time recovery is limited to that.