Install co:op and sign in
co:op runs your coding agent in a disposable container on your computer. You will use Docker and a terminal for this walkthrough. The agent edits the project you start it from, so choose a checkout where you can review its changes.
Host terminal
curl -fsSL https://coop.dryga.com/install.sh | sh
The installer runs a downloaded script. For checksums and release verification, use the installation reference.
coop versioncoop login claude
Sign in to Claude Code. co:op uses your provider account, with that account’s model access and usage limits.
Using Codex instead?
Sign in with this command, then use coop codex in step 5. The project, file and network checks are the same.
coop login codex
Before you continue
coop version prints the installed version, Docker is running, and sign-in has completed for your chosen provider.
Initialize the checkout you will use
In your terminal, change into the root of your Git project. Check for existing work, then initialize co:op there.
Host terminal · project root
git status --shortcoop init
Review or commit any changes you already have so you can tell them apart from the agent’s work. To work in a separate copy, follow the fork workflow before starting the agent.
A new project uses filtered networking. co:op keeps any existing project settings, so read .agent/project.yaml and the generated instructions to check how your project is configured.
Before you continue
You know which checkout will change, and you have reviewed its co:op configuration. A disposable container does not undo edits to the mounted project.
Decide what the agent can read
co:op hides common secret files, including environment files and private keys, from the container. Check for other private data in your project, including files ignored by Git.
Host terminal · project root
coop check-secrets --include-ignored
Inspect every reported file and line. Remove real credentials from files you intend to commit, fix unreadable files, and rerun the scan. The command returns a nonzero status if it finds a problem or cannot finish the scan.
The scanner cannot recognize every secret. Check for sensitive business data yourself and decide what the agent needs to read.
Add any other private paths to your existing .coopignore. This example hides a notes directory and a customer export:
.coopignore · example additions
private-notes/ customer-export.csv
.coopignore hides files when the agent starts. Git ignore rules do not. Hiding a file does not remove it from Git or dismiss a scanner finding. Restart the agent after changing which files should be hidden.
If you have checked a finding and confirmed it is a false positive, add the exact entry and reason the scanner requests to .coopsecretsignore.
The boundary to remember
Visible project files and anything you put in a prompt may be sent to the allowed AI provider. Include only the data this task needs.
Check the network and the sandbox
Check what a new run can reach before starting the agent.
Host terminal · project root
coop net
For this walkthrough, use filtered access. The agent should reach only its provider and the destinations you approved. If coop net shows open access or an unfamiliar rule, check the networking configuration before starting.
If the report says new runs need your approval, run coop approve on the host and review the requested access. Approve only the destinations you need. A new filtered project with no extra rules needs no approval.
If your project has an .agent/Dockerfile, review it and the files it copies, then build the image before launching the agent:
Host terminal · project root · when using a project image
coop build
The run’s filtered network rules do not apply during this build. If you change the Dockerfile or its inputs later, rebuild and restart the agent.
Now run co:op’s isolation checks:
Host terminal · project root
coop doctor
Read the full report, including checks it could not run. Fix failed checks and follow any setup instructions before continuing. A successful exit alone does not mean every check ran. These checks also do not verify your project’s secrets, dependencies or tests.
A dependency or documentation site is blocked
On the host, run coop net blocked <host> with the exact hostname that was blocked. Read the proposed rule and add the access you need to .agent/project.yaml. Review it with coop approve, then exit and restart the terminal agent session to use the new access.
The networking reference explains rule syntax and approval.
Before you continue
You have reviewed the network access and the isolation report, and resolved any failures or setup problems.
Start with a task you can inspect
Launch the provider you signed in to. On the first filtered run, co:op prepares its own images and checks that Docker can enforce the network rules. It starts the agent only if those checks pass.
Host terminal · the same project root
coop_review_base=$(git rev-parse HEAD)coop claude
The first command saves the starting commit in your host shell. If it fails, stop and fix the problem before starting the agent. Keep this terminal open for the final review. If you use another terminal, find that original commit before comparing changes. Comparing with the latest commit could miss work the agent has already committed.
For Codex, run coop codex instead. A useful first prompt asks the agent to understand the project before changing it:
Example prompt · inside the agent
Read AGENTS.md and find the command for the project’s focused tests. Explain which files and services the check needs. Do not edit files or install dependencies yet. If anything is missing or blocked, report it and wait.
Check its answer against the repository. Then ask for one small change, tell it which check to run, and ask it to stop when it can explain what changed and whether the check passed.
If a check needs a tool or service missing from the container, follow the project image or services documentation to set it up before expanding the task. Filtered runs do not install your project’s build tools automatically.
After setting up the tools and services, have the agent run your project’s actual check in the container. Fix any remaining setup problems before attempting an unattended run.
Exit the agent with its normal quit command. Back in the same host terminal, inspect new files, commits, and the complete tracked diff from the starting commit:
git status --shortgit log --oneline "$coop_review_base"..HEADgit diff "$coop_review_base"
The diff shows all tracked changes since the starting commit, including work the agent staged or committed. Open any untracked files separately; their contents are not in this diff. Run the relevant project checks yourself and try the behavior you asked the agent to change.
Before you continue
You have reviewed every changed file and can explain the result. The relevant project checks pass when you run them yourself.
Build on a verified first run
Keep the next task small until the project builds and tests reliably inside the container. For a queue that can continue without your supervision, use the overnight walkthrough.
Other runtimes and editor sessions
Use Docker for the provider sessions in this guide. It supports the helper that keeps your provider credentials outside the container. Apple container can run commands with open networking and no credentials, but cannot replace Docker for this setup.
An agent connected through ACP can ask your editor to read files or run commands on your computer. The editor controls that access. Read the editor documentation before using it.