Agentic coding
How to use
Cline.
Planning, implementing, testing, and reviewing multi-file software changes with visible tool use and configurable approvals.
Cline is a open-source agentic coding assistant for editors and terminals. Planning, implementing, testing, and reviewing multi-file software changes with visible tool use and configurable approvals. This guide covers the whole path in one place: official access, a first session that produces something reviewable, the checks that make output trustworthy, and the permissions worth limiting before you connect real work.
AI should make the work easier to inspect. If the workflow removes the source, the owner, or the review step, redesign the workflow.
Access & setup
Find, install, and sign in to Cline
Get into the official Cline experience with the right account and a setup you understand.
- 01
Start at https://cline.bot/ and confirm the domain before entering account or payment information.
- 02
Availability: Available as an editor extension and command-line tool, with model-provider configuration chosen by the user.
- 03
A supported editor or terminal environment, access to a compatible model provider or local model, and a repository with appropriate backups and permissions.
- 04
Sign in with the account you intend to keep using, then review plan, data, notification, and permission settings.
- 05
Run one low-risk test task before connecting sensitive files, repositories, or workspace data.
- Use official download pages.
- Review permissions during setup.
- Keep installers and applications updated.
First session
Your first useful Cline session
Learn the interaction loop using a small task with a clear outcome.
- 01
Open a clean branch and give Cline a bounded task with expected behavior and relevant file references.
- 02
Use Plan mode to inspect the codebase and agree on the files, risks, tests, and implementation sequence.
- 03
Confirm Checkpoints are enabled, move to Act mode, and approve only the required edits and commands.
- 04
Review the final diff, test results, and git status before committing the change yourself.
- State the outcome before the background.
- Provide the real source material.
- Review the result before expanding the task.
Quality control
Check the quality of Cline output
Turn generated code into a change you would put your name on in review.
- 01
Restate the intended behaviour and the acceptance criteria before reading a single generated line.
- 02
Read the diff rather than the chat summary; the summary describes intent, the diff describes what actually changed.
- 03
Run the test suite, then write a test that would fail if the change were wrong, and confirm it passes for the right reason.
- 04
Check the edges the model tends to skip: error paths, null and empty cases, concurrency, and migration or rollback behaviour.
- 05
Trace every new dependency, network call, and file write, and confirm each one is genuinely required.
- Review the diff, never the description of the diff.
- A passing test suite proves the tests pass, not that the change is correct.
- Keep changes small enough that a human can actually review them.
Privacy & permissions
Use Cline safely
Give the tool enough repository access to help, and no more than that.
- 01
Decide what the tool may read and what it may write before connecting a repository.
- 02
Scope tokens and integrations to the narrowest repository, branch, and permission set that still works.
- 03
Keep secrets out of the context window: use environment variables and secret stores, never inline credentials.
- 04
Require review before generated code touches authentication, payments, permissions, migrations, or deletion paths.
- 05
Audit what the integration retained after the session, and revoke access that is no longer needed.
- Cline can edit files, execute commands, browse, and invoke MCP tools. Keep permissions narrow, protect credentials, review diffs, and reserve broad Auto Approve or YOLO mode for isolated disposable environments.
- Follow your organisation's approved-use policy.
- Never treat fluent output as authorization to act.
Core workflows
Step-by-step ways to use Cline for the work it does best.
Each workflow below has its own outcome, steps and review checkpoints.
Move from codebase investigation to an implemented and verified change without surrendering review control.
↓ 02 WorkflowSet safe Cline permissions for daily developmentTune Auto Approve and tool access so routine inspection stays quick while consequential actions remain visible.
↓Workflow 01
Complete a controlled repository task with Cline
Move from codebase investigation to an implemented and verified change without surrendering review control.
Outcome: Finish a scoped coding task with a clear plan, reviewable diffs, and evidence that the change works.
- 01
Start on a clean branch, describe the expected behavior and constraints, and point Cline to the relevant files and project instructions.
- 02
Use Plan mode to inspect the repository, identify affected code and tests, surface assumptions, and agree on a bounded implementation plan.
- 03
Confirm Checkpoints are enabled, switch to Act mode, and approve file edits and commands individually unless a narrow action is already trusted.
- 04
Review each diff and terminal result, redirect Cline when scope expands, and restore the last good checkpoint if the approach goes wrong.
- 05
Run the project checks, inspect the final diff and git status yourself, then commit only after the acceptance criteria are demonstrated.
What good use looks like
- Plan before medium or large changes.
- Keep destructive actions approval-gated.
- Treat tests and the final diff as the completion evidence.
Workflow 02
Set safe Cline permissions for daily development
Tune Auto Approve and tool access so routine inspection stays quick while consequential actions remain visible.
Outcome: Create a reusable permission posture matched to the repository and the sensitivity of its data.
- 01
Classify the workspace, credentials, external services, and commands that could modify data, dependencies, git history, or production systems.
- 02
Enable project-file reading first and leave edits, terminal commands, browser access, and MCP tools approval-gated until each is needed.
- 03
If repetitive work justifies Auto Approve, enable only the smallest categories and keep access outside the workspace disabled.
- 04
Test the policy on a disposable branch with representative read, edit, test, install, network, and destructive requests.
- 05
Keep Checkpoints and normal version control active, review permission changes periodically, and avoid YOLO mode outside isolated throwaway work.
What good use looks like
- Grant capabilities by task, not convenience.
- Keep secrets outside agent-readable files.
- Re-test permissions after extensions or MCP servers change.
Official references
Check the current product documentation.
Features, plan limits, availability, and data controls change. These official pages are the starting points used for this guide.