Using Claude, Codex or OpenCode for defensive code review: permissions, isolation and risk

Key takeaways

• AI command-line runners are powerful tools, but models remain probabilistic systems that can misinterpret instructions or attempt unexpected actions.
• Do not rely solely on prompt instructions or CLI flags for safety; enforce OS-level isolation around the user account that runs the model.
• If you do not want an AI runner touching Git remotes or SSH keys, sync repositories via a cron job and copy source into a restricted Unix user account for Dokima.
• Always verify your model provider's commercial data-retention and training policies before running cloud-hosted models over proprietary code.

Why operational isolation matters when running AI code reviewers

Command-line AI runners such as Claude Code (claude), OpenAI Codex CLI (codex) and OpenCode (opencode) give models the ability to read files, search directories and reason over real repositories. That makes them far more capable at security analysis than a browser chat window.

At the same time, security-minded engineering teams rightly ask: What stops an AI runner from modifying source files, accessing production credentials in my home directory, or pushing something to Git?

The honest answer in security engineering is defence in depth. While Dokima issues structured defensive-review instructions and invokes runners with read-only settings, AI models remain probabilistic systems. An untrusted file inside a repository could contain prompt-injection text, or a model or CLI runner could behave unpredictably. You should configure the operating environment so that even if a model attempts an uninstructed action, the operating system refuses it.

What Dokima configures at the runner and workspace layer

When Dokima runs a review stage on your machine, it enforces several boundaries out of the box:

• Read-only runner execution: Dokima invokes supported runners with read-only permissions for source analysis and prohibits repository modification in its stage instructions.
• Protected scheduler state: Worker lifecycle metadata is kept outside the runner-accessible workspace under ~/.local/state/dokima/workers/ with 0600 socket permissions and singleton/writer locks, and stage transitions only advance when output passes strict schema validation.
• Explicit publishing consent: Dokima never uploads vulnerability findings to Dokima.net unless you explicitly select private team publishing during setup or in Settings.

However, application-level flags are only the first layer. If you run any CLI tool under your personal developer login, that process inherits your Unix user permissions unless restricted further.

How to run Dokima without giving the model Git access or developer credentials

On a developer laptop, your user account often holds SSH keys, cloud CLI tokens (~/.aws, ~/.config/gcloud), production .env files, and push access to Git remotes.

If you prefer not to give your AI runner access to Git credentials or your main user profile, the cleanest pattern on Linux or macOS is to run Dokima inside a dedicated, restricted Unix user account fed by a scheduled source copy:

1. Create a dedicated unprivileged user (for example, dokima-runner) that has no SSH keys, no Git push credentials, and no cloud provider tokens.
2. Sync Git outside the restricted account: Use a root or deployment-user cron job (or systemd timer) to run git fetch and git reset --hard in a staging clone that has read-only repository deploy keys.
3. Copy or rsync the source tree into the dokima-runner workspace directory (preserving .git metadata if you want commit tracking, while stripping any remote credentials or hooks, or syncing a clean source snapshot).
4. Run Dokima as the restricted user: Start the Dokima worker or systemd user service under dokima-runner. The AI model can read the copied source tree and write its report to dokima-report/, but has zero access to your developer home directory or upstream Git server.

Checking model provider terms vs running local models

Alongside OS permissions, make sure your model configuration matches your organisation’s data classification policy:

• Commercial Claude or Codex accounts: When you use Claude Code or Codex CLI, prompts and relevant source excerpts are sent directly from your machine to Anthropic or OpenAI. Verify that your subscription tier or API agreement disables training on customer data and meets your regional data-residency requirements.
• Other commercial providers via OpenCode: If you route OpenCode through Google Gemini, AWS Bedrock, Azure or another gateway, your traffic is governed by that provider’s terms and retention settings.
• Self-hosted local models via OpenCode: If no source code may leave your network, configure OpenCode against a local OpenAI-compatible inference server and select Local HTML reports only in Dokima. See our guide on running AI code security review with local models.

Practical pre-flight checklist before your first sweep

Before starting a continuous review on sensitive repositories:

• Confirm that no live production secrets or .env files with active credentials are sitting uncommitted inside the workspace directory.
• Decide whether Dokima should run under your normal account or a restricted Unix user fed by a cron job.
• Check dokima runner settings so only your approved runner (claude, codex, or opencode) is enabled.
• Choose between Local HTML reports only and Publish privately to Dokima.net.

Review our Getting Started guide and Data handling documentation, or start a 21-day free trial to test Dokima in your environment.