Sandbox-aware coding agent
How to use
CodeBuddy.
Running complex coding tasks with visible artifacts and diffs while combining layered allow, ask, and deny rules with directory trust and OS-level shell sandboxing.
CodeBuddy is a AI coding environment from Tencent Cloud with IDE, agent, and command-line workflows. Running complex coding tasks with visible artifacts and diffs while combining layered allow, ask, and deny rules with directory trust and OS-level shell sandboxing. 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 CodeBuddy
Get into the official CodeBuddy experience with the right account and a setup you understand.
- 01
Start at https://www.codebuddy.ai/ and confirm the domain before entering account or payment information.
- 02
Availability: CodeBuddy provides a standalone AI IDE and CodeBuddy Code CLI with agent tasks, parallel work, model selection, subagents, permission modes, hooks, MCP tools, and optional shell sandboxing.
- 03
A supported desktop or terminal environment, a CodeBuddy account or approved provider configuration, a trusted repository, and reviewed file, command, network, model, and data boundaries.
- 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 CodeBuddy session
Learn the interaction loop using a small task with a clear outcome.
- 01
Install the official IDE or CLI and open a clean branch in a repository you have explicitly reviewed and trusted.
- 02
Start in plan or default permission mode, add deny rules for secrets and release actions, and enable sandboxing for shell work.
- 03
Give one agent task explicit acceptance criteria, relevant paths, non-goals, and validation commands.
- 04
Inspect the artifact, command history, changed files, tests, and final diff before any commit or external action.
- State the outcome before the background.
- Provide the real source material.
- Review the result before expanding the task.
Quality control
Check the quality of CodeBuddy 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 CodeBuddy 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.
- Directory trust, tool permissions, permission mode, and shell sandbox are separate controls. Use explicit deny rules as hard boundaries, keep bypass permissions disabled, prevent unsandboxed retries where not needed, restrict additional directories and network domains, review project settings before trusting a clone, cap parallel agents, keep credentials short-lived, and independently verify all code, tests, commands, commits, pushes, and deployments.
- Follow your organisation's approved-use policy.
- Never treat fluent output as authorization to act.
Core workflows
Step-by-step ways to use CodeBuddy for the work it does best.
Each workflow below has its own outcome, steps and review checkpoints.
Combine plan mode, explicit deny rules, and shell sandboxing to produce a reviewable change.
↓ 02 WorkflowConfigure a governed CodeBuddy CLI policyLayer user, project, and local settings so teams gain useful defaults without letting a cloned repository silently expand authority.
↓Workflow 01
Complete an isolated repository task with CodeBuddy
Combine plan mode, explicit deny rules, and shell sandboxing to produce a reviewable change.
Outcome: Finish a scoped coding task without confusing repository trust, tool approval, and operating-system isolation.
- 01
Create a clean branch or disposable checkout, inspect repository settings and hooks, and capture the starting status and baseline tests.
- 02
Start in plan or default mode, add deny rules for secrets, Git metadata, pushes, deployments, and unrelated paths, then enable a restricted shell sandbox.
- 03
Provide the outcome, acceptance criteria, relevant files, architecture constraints, non-goals, validation commands, and a clear stop condition.
- 04
Review the plan and every consequential tool call, rejecting extra directories, network domains, unsandboxed retries, dependency drift, or parallel tasks without need.
- 05
Run trusted tests independently, inspect artifacts and the complete diff, clean temporary credentials, and use the normal human-reviewed commit and release process.
What good use looks like
- Use deny rules for hard boundaries.
- Keep shell work sandboxed.
- Treat directory trust and tool approval separately.
Workflow 02
Configure a governed CodeBuddy CLI policy
Layer user, project, and local settings so teams gain useful defaults without letting a cloned repository silently expand authority.
Outcome: Create an auditable permission and sandbox baseline that behaves safely in interactive and non-interactive sessions.
- 01
Inventory approved directories, commands, domains, MCP tools, models, subagents, credentials, environments, and actions that always require a person.
- 02
Put shared least-privilege ask and deny rules in reviewed project settings while keeping machine-specific paths and credentials in uncommitted local or user scope.
- 03
Disable bypass and auto modes where policy requires, enable sandbox filesystem and network allowlists, and disable unsandboxed escape when unnecessary.
- 04
Test trusted and untrusted clones, protected files, dangerous command variants, redirects, chained commands, prompt injection, subagents, and non-interactive fallbacks.
- 05
Audit effective rules in the permission panel, version owner-approved settings, rotate secrets, and rerun the test matrix after every CodeBuddy upgrade.
What good use looks like
- Never commit credentials.
- Test effective rules from an untrusted clone.
- Deny unsandboxed escape unless required.
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.
- CodeBuddy Agent Mode ↗
- CodeBuddy permission rules ↗
- CodeBuddy shell sandbox ↗
- CodeBuddy security guidance ↗