Most AI coding tools sit beside you while you type. OpenClaw’s coding agent does something different: it goes off and works on its own. You point it at an issue, and it reads the issue, finds the relevant code, writes a fix, runs the tests, and opens a pull request — as a background process, while you do something else. You come back to a PR to review, not a half-finished suggestion in your editor.
That autonomy is genuinely useful and genuinely needs guardrails. This tutorial covers how the coding agent works, how to set it up, and how to keep an agent that writes and pushes code from doing something you didn’t want. If OpenClaw isn’t installed yet, start with the install guide.
How it actually works
The coding agent is a skill — a background worker the OpenClaw daemon runs. The loop looks like this:
- Read the task. An issue, a description, or a message you send through a channel.
- Explore the code. It reads the repo to understand the relevant parts.
- Write the fix. It edits files to implement the change.
- Run the tests. It checks its own work against the suite.
- Open a pull request. The change lands on a branch for your review.
The difference from an inline assistant is step 5 and the fact that 1–4 happen without you. You’re not approving each edit as it goes; you’re reviewing a finished, tested change at the end.
Step 1: enable the coding-agent skill
In OpenClaw, enable the coding-agent skill and make sure a capable model is behind it. The skill needs the model to do the reasoning and code-writing, so model choice matters — a decent mid-tier model handles most fixes. A cheap option like DeepSeek is a fine starting point; switch up only if the quality of fixes lags.
Confirm the current skill name and config against the OpenClaw repo, since skill setup evolves.
Step 2: give it scoped repo access
The agent needs to read the repo, write changes, and open PRs. That means repository access and a token. The rule here is least privilege:
Access the coding agent needs
| Capability | Scope it to |
|---|---|
| Read the repo | The specific project, not everything |
| Write changes | A working branch, never directly to main |
| Run tests | The project's test command |
| Open PRs | A token scoped to that one repository |
Step 3: hand it a task
With the skill enabled and access scoped, give it work. Through your terminal or a connected channel:
Fix issue #214: the date parser crashes on empty input.
Write a fix, add a test for the empty case, and open a PR.The agent reads the issue, finds the parser, makes the change, adds the test, runs the suite, and opens a pull request. You get a notification (especially handy if you’ve wired up a messaging channel) and review the PR like you would a colleague’s.
A good first task is small and well-defined — a clear bug with an obvious test. Save the sprawling, ambiguous work for when you trust how it behaves.
Step 4: review like you mean it
The agent’s PR is a draft of a fix, not a guaranteed-correct one. Review it properly:
- Does the fix actually address the issue, or just make the symptom go away?
- Is the test meaningful, or does it pass trivially?
- Did it change anything it shouldn’t have touched?
- Do all the tests genuinely pass?
This review step is non-negotiable. The whole safety model rests on a human checking the change before it merges. An agent that’s right most of the time still needs the gate for the times it isn’t.
Coding agent setup checklist
- Coding-agent skill enabled with a capable model behind it
- Repo access granted, scoped to the one project
- Token limited to that repository; no push to protected branches
- Agent opens PRs only — no auto-merge
- First task small and well-defined
- Every PR reviewed before merging
Where it shines and where it doesn’t
The coding agent is great at bounded, well-specified tasks: a clear bug with a reproducer, a small feature with obvious acceptance criteria, a refactor with tests to catch regressions. It can chew through a backlog of small issues while you focus on the hard stuff.
It’s weaker on ambiguous, design-heavy work where the “right” answer depends on judgment and context it doesn’t have. For those, you’re better off in an interactive tool. If you want a dedicated coding agent rather than a general assistant with a coding skill, the comparison in OpenClaw vs Claude Code is worth reading.
Wrapping up
OpenClaw’s coding agent turns “fix this small bug” into a background task that comes back as a reviewed-ready pull request. Enable the skill, put a capable model behind it, scope its repo access and token tightly, and keep it to opening PRs that you review before merging. Start with small, clear tasks, and let it earn more autonomy as you see how it works.
For the autonomous-GitHub angle, start with a small test repository, a scoped token, and PR-only permissions before letting the agent near production code.
