Set up Doomer in Claude
Use this guide for Claude Code in a terminal/TUI or graphical UI, on macOS or Linux. Begin with a team or personal skill installation. Quick reviews do not require a Doomer account.
Using Claude Chat or Cowork instead? Its code-execution network controls are separate from Claude Code. Follow Chat and Cowork in an organization or Chat and Cowork on a personal account below. The terminal hook commands in this guide apply to Claude Code.
Choose your environment
| Where you work | Where to install and configure Doomer |
|---|---|
| Claude Code terminal/TUI on macOS | Your Mac, under the user running claude. |
| Claude Code terminal/TUI on Linux | The Linux machine, container, or VM running claude. |
| Claude desktop UI with a local checkout | The local environment used by that coding session. |
| Desktop or browser UI with a cloud/remote checkout | The environment that edits the checkout, even when the app runs on your Mac. |
The agent-led installer selects the correct OS and architecture on macOS and Linux. A desktop installation does not install Doomer in a remote VM. A browser or Remote Control session can point to a local process: use the execution location, not the appearance of the UI, to choose the setup path.
1. Install the skill
Open the repository in Claude Code, or select it for your graphical coding session, and paste:
Read https://doomer.ai/install.md and follow the instructions to set up Doomer in this repository.
Use a team installation so I can commit the skill and share it with my teammates.Replace the second sentence with “Use a personal installation” for your own environment only. The agent-led route does not require Node.js or Homebrew. Alternatively, with Node.js 22.20 or later, run this at the repository root and select Claude Code and the project scope:
npx skills add doomerlabs/skills --skill doomer-reviewAsk Claude to finish setup after a manual installation. Commit the generated skill files and skills-lock.json to share the instructions with teammates.
2. Complete upload approval and hooks
Follow the setup link the agent returns and review the upload scope. Approved reviews send repository snapshots, task context, and finding responses to Doomer. Each developer chooses whether to allow this; committed skill files do not grant permission for the team.
During setup the agent configures its hooks with:
doomer hooks --agent claudeThe CLI adds Doomer entries to ~/.claude/settings.json and preserves unrelated settings and hooks. Restart Claude Code if needed so it loads the changes. In the terminal, use /hooks to inspect the configured entries. Follow any review or permission prompts your client presents. In a graphical session, ask Claude to confirm the configuration in its execution environment.
Configuration alone does not prove activation. Give Claude a small coding task and confirm that Doomer received a real callback and returned a review with recorded agent responses. If that client cannot activate hooks, the skill can use explicit review commands during the task.
You’re ready when…
- The agent returns a quick-review link, and the review of your latest changes has completed.
- Each hypothesis has an accept, reject, or defer decision and an explanation in Feedback. A completed review can also return no hypotheses.
- If using hooks, Doomer has received a real callback from this session. Until then, the skill can submit reviews explicitly; installed hooks alone do not prove activation.
3. Allow the required domains
A network allowlist controls which hosts Claude can reach. It is separate from permission to upload repository content. Use the exact hostname in the failed operation's required_host field; do not paste a full URL, path, or signed upload URL into an allowlist.
| Host | Why it may be needed |
|---|---|
doomer.ai | Installation instructions, setup, and review API calls. |
downloads.doomer.ai | Downloading the Doomer CLI. |
raw.githubusercontent.com, api.github.com, github.com | Fetching the installation guide and scripts, release metadata, or checksums. |
| A storage hostname reported during upload | Uploading an approved snapshot; use the exact host the CLI reports. |
These are purposes to check, not a requirement to allow every host in advance. A custom Doomer service may report a different API host. The optional npx route also needs its package-registry access. Preserve existing domains and add only those needed for the operation.
Chat and Cowork in an organization
In the Claude organization settings shown below, add both production domains:
- Open Organization settings → Capabilities in the organization running your task. An organization owner manages these controls.
- Scroll down to Code execution. Ensure code execution and Allow network egress are enabled, if your organization's policy permits them.
- Under Domain allowlist, keep Package managers only to retain package-registry access, or your organization's existing restricted option.
- Under Additional allowed domains, enter
doomer.aiand select Add. Repeat fordownloads.doomer.ai. Leave existing domains in place. - Confirm both hosts appear in the list and save or confirm if your interface prompts you. Return to the task and retry the blocked operation.
Organization settings → Capabilities → Code execution. This screenshot was sanitized to remove a personal development domain. It shows the two production Doomer hosts, not a wildcard.
These are the Chat/Cowork controls, not the per-environment settings for Claude Code cloud sessions. Allowing a host enables the connection; repository-upload approval still happens separately. For the supported organization controls, see Claude's code-execution network settings.
Chat and Cowork on a personal account
For a personal account, start at Settings → Capabilities, rather than Organization settings. Claude documents Code execution and file creation (called Create and edit files in the updated layout) and network egress there. See Claude's personal skill prerequisites.
The organization screenshot above does not establish that a personal account has the same domain editor. That editor's personal-account layout has not been verified here. If a connection is blocked, use the exact hostname from the error and the network controls available in your account; do not assume the organization path applies.
Local Claude Code terminal/TUI or desktop session
For Claude Code's sandbox, merge the required hosts into sandbox.network.allowedDomains in your personal ~/.claude/settings.json. For example, after reviewing access to the production API and CLI downloads:
{
"sandbox": {
"network": {
"allowedDomains": ["doomer.ai", "downloads.doomer.ai"]
}
}
}This is a fragment to merge, not a replacement for your settings file. Keep existing hooks and allowed domains. Use /sandbox in the terminal to inspect the sandbox. If managed settings restrict domains, an administrator must allow them; a personal setting cannot override that policy. See Claude's sandbox documentation.
Claude Code cloud session in the browser or desktop UI
- Check which cloud environment the session uses.
- From the new-session environment selector, open that environment's settings. For a running session you own, open the menu beside its title and choose Edit cloud environment.
- Open Network access, select Custom, and add the exact host under Allowed domains, one host per line. Keep existing entries and retain Also include default list of common package managers if your workflow needs those defaults.
- Save the environment and return to the task. Organization-shared environments may require an owner to make the change.
These controls belong to the cloud environment; editing your Mac's settings file does not change them. See Claude's cloud environment documentation.
Organization-shared Claude Code cloud environments
A shared environment's settings open read-only in the selector. An organization owner edits its allowlist from the Cloud environments page in admin settings. These Claude Code cloud allowlists belong to individual environments; the Chat/Cowork organization allowlist above does not replace them. Use a shared environment when your team needs a common list.
4. Retry and verify
After saving the appropriate setting, ask Claude to run the CLI's returned retry_command once. It keeps the existing Doomer task and setup progress. Claude Code cloud-environment network changes normally reach existing sessions within about a minute. If the same request still fails, check the active environment and the safe error details before retrying again. For local settings changes, restart Claude Code if needed. Ask the agent to resume the existing task rather than creating another.
A later upload may need a different storage host than setup. Review that exact host when it is reported. An HTTP 403 can also indicate a service or authentication problem; it does not by itself prove the allowlist is responsible.
Troubleshooting
| Symptom | Check |
|---|---|
| Works on macOS but fails in Linux/cloud | Check the CLI installation and network policy in the Linux environment. |
| Hooks are configured but no review appears | Restart the client if needed, check for a real callback, and have the skill use explicit review calls while activation is unverified. |
| Adding a domain has no effect | Confirm the active organization/environment and managed policy. Local sandbox, organization, and cloud settings are different controls. |
| Need diagnostics | Run doomer doctor --repo . --no-upload to create a local report without uploading it. |
Continue with Run your first quick review, or see Codex setup if you use both agents.