I Let Cline Drive My Editor For a Week. Here Is the Config That Made It Safe
How I wired Cline's Plan/Act split, checkpoints, and Playwright MCP into one VS Code setup I actually trust to run on its own.
I have a bad habit. The second a coding agent gets even slightly good, I want to see how far it goes before it does something dumb. Cursor never let me do that comfortably, the agent felt too eager and too hidden at the same time. So I spent a week living inside Cline, the open-source agent that lives right in VS Code, and tried to build a setup where I could hand over the wheel without white-knuckling the keyboard.
Short version: it worked better than I expected, and the reason was not the model. It was two boring features. The Plan/Act split, and checkpoints. Once those were in place I stopped babysitting and started reading a book while it worked. Here is the whole thing.
Claude Sonnet 4.6. MCP servers: filesystem, github, playwright. One subagent (plan-act-worker). Hook: format on save. Bring your own API key.Why Plan mode is the whole trick
Cline splits a task into two phases. In Plan mode it reads your code, asks questions, and writes out what it intends to do, but it cannot touch a single file. In Act mode it actually edits. That sounds like a small UI choice. It is not. It is the difference between an agent that surprises you and one that negotiates with you.
My first rule, written into the project, is that nothing skips Plan. I want a paragraph of intent before any diff shows up. If the plan is wrong, I correct it in chat and it costs me nothing. If the plan is right, I hit Act and walk away.
# How you work in this repo
- Always start in Plan mode. Describe the change and the files you
will touch before switching to Act. Do not edit in Plan.
- Read the relevant file before you propose a diff to it. No guessing.
- Prefer small, reversible steps. After each meaningful edit, pause
so a checkpoint is created.
- Risky terminal commands (rm, migrations, git push, anything that
hits the network or deletes) need my explicit yes, every time.
- When a UI change is involved, verify it with the Playwright MCP
before you tell me you are done.
- Match the existing code style. We have Prettier on save, so do not
hand-format.Auto-approve, but only the harmless stuff
The fun of autonomy dies fast if you have to click Approve forty times for the same read-only command. Cline lets you auto-approve categories. I open the gate for reading files and running safe, read-only commands, and I keep it shut for edits to files outside the workspace and anything that touches the shell in a destructive way.
{
"cline.autoApprove": {
"readFiles": true,
"listFiles": true,
"runSafeCommands": true,
"editFiles": false,
"executeAllCommands": false,
"useMcpServers": true
},
"cline.autoApprove.maxRequests": 25,
"cline.checkpoints.enabled": true,
"cline.planActMode": "plan-first"
}That maxRequests cap is my safety valve. After 25 auto-approved actions in a row Cline stops and checks in with me, even if everything was technically allowed. It stops the agent from quietly grinding through my token budget on a wild goose chase. I learned that the expensive way on a refactor that went sideways.
Checkpoints are the undo button I always wanted
Every time Cline makes a change, it snapshots the workspace. So when it goes off and rewrites three files into something I hate, I do not git stash and sigh. I click a checkpoint and the whole thing rolls back to a known-good state, agent context included. This is the feature that let me stop fearing the Act button. The worst case is no longer a mess. The worst case is a click.
Giving it real tools with MCP
Cline speaks the Model Context Protocol, so the agent is only as capable as the servers you plug in. I run three. Filesystem so it can range across the repo cleanly, github so it can open and read PRs and issues without me copy-pasting, and playwright so it can actually look at the UI it just changed instead of claiming victory blind.
{
"mcpServers": {
"filesystem": {
"command": "npx",
"args": ["-y", "@modelcontextprotocol/server-filesystem", "."]
},
"github": {
"command": "npx",
"args": ["-y", "@modelcontextprotocol/server-github"],
"env": { "GITHUB_TOKEN": "${env:GITHUB_TOKEN}" }
},
"playwright": {
"command": "npx",
"args": ["-y", "@playwright/mcp@latest"]
}
}
}The Playwright one is the star of this build. A coding agent that can read its own UI changes is just on another level from one that types code and hopes. It caught a z-index bug for me before I ever looked at the page, which felt slightly uncanny and also exactly why I do this.
punkpeye/awesome-mcp-serversThe list I raid whenever I want to bolt a new sense onto the agent. Filesystem, github and playwright all started here for me.github.com/punkpeye/awesome-mcp-servers38kModel Context Protocol - SpecificationWorth a skim if you want to understand why MCP servers compose the way they do instead of treating it as magic glue.modelcontextprotocol.io
14:27The one hook I keep
I am not a hooks maximalist. The more automation you stack on an agent, the more you have to debug when something quietly breaks. So I run exactly one: format on save. Cline edits, the file saves, Prettier runs, done. It means the agent never wastes a thought on indentation and my diffs stay clean.
{
"editor.formatOnSave": true,
"editor.defaultFormatter": "esbenp.prettier-vscode",
"[typescript]": { "editor.formatOnSave": true },
"[typescriptreact]": { "editor.formatOnSave": true }
}What this setup is actually good at
I would not hand this a vague greenfield mega-task. Where it shines is the middle ground: a well-scoped feature in an existing codebase, where I can describe the shape in Plan, let it Act, and trust the checkpoint net under it. Here is roughly how it lands for me.
| Task type | How it goes | Do I watch? |
|---|---|---|
| Scoped feature in known code | Strong, reliable | Barely |
| UI tweak that needs visual proof | Great, thanks to Playwright | No |
| Big architectural change | Risky, plan drifts | Closely |
| Schema / db migration | Keep it on a leash | Every step |
- Speed per task in my logs sits around 2.2s before edits stream in. Snappy enough that the Plan/Act loop never feels like waiting.
- Cost lands near $0.16 a task on Sonnet 4.6 with my own key, which is the part that lets me experiment without flinching.
- Pass rate hovers around 79 percent on my own messy real-world tasks. Not flawless. Reversible failures are fine when rollback is one click.
The setup I trust is not the most powerful one. It is the one where being wrong is cheap.
That is the build. Open source, your own keys, your own rules file, and an agent you can actually watch think before it touches anything. If you have been put off by agents that feel like black boxes, the Plan/Act split is the thing to try first. It scratched the exact itch Cursor never quite reached for me.
Install Cline from the VS Code marketplace, or grab it in the extensions pane with ext install saoudrizwan.claude-dev, drop in your API key, paste the .clinerules above, and start everything in Plan. Go let it drive for an afternoon. Report back.