Skip to main content
This page describes Corbits Code, the app. It does not describe credentials or grants held by the control plane, and it does not speak for the shared agent runtime.

​
Steering a run

You are not just watching. While a run is in progress:
  • Enter steers mid-run. Type a correction and the agent picks it up on its next turn.
  • Alt+Enter queues a follow-up for when the session goes idle.
  • Ctrl+C interrupts.
  • Tab moves focus between the prompt and the transcript. Shift+Tab cycles reasoning effort for the current model.
  • /help lists every command. (keyboard shortcuts)
Corbits Code starts in auto mode: it edits files in your workspace and runs ordinary shell commands without asking each time. A curated set of riskier shapes still stop for your approval, among them dependency installs, recursive deletes, paths outside the workspace, anything referencing a credential file, network uploads, and changes to git’s global config. Writing files through the shell, with a redirect or sed -i, is refused outright rather than queued for approval, so the agent uses the file tools where you can see the diff. Start with --no-auto if you would rather approve every consequential action while you get a feel for it. (runtime configuration; auto-mode shell policy) On your first run, you can explicitly enter /yolo to give Corbits Code full access to commands and capabilities. /yolo is not the default: Corbits Code may still ask questions related to your task, but it does not ask you to approve actions. (yolo command)

​
Safety you can’t talk it out of

Corbits Code enforces safety at the tool layer, as middleware wrapped around every tool call, not as advisory text a model can reason around. One layer owns each constraint, and the agent cannot evade a constraint by rewording its request.
Read-only tools (reading files, searching, listing directories) run freely. Corbits Code starts in auto mode, where file writes, edits, and deletes run without a prompt and only riskier shell shapes stop for one. Pass --no-auto to be asked before every consequential action.When you are asked, you approve with Allow Once or Allow Always. Allow Always remembers the choice for the rest of the session. The permission store also supports per-project, global, and per-provider-model grants, visible and revocable through /permissions, but the approval prompt itself doesn’t yet offer a way to choose one of those broader scopes. (permission gate; permission administration)
Sensitive files are protected at two different strengths. A path-keyed tool argument naming one is hard-denied outright. A shell command that merely references one is forced to an operator prompt that no remembered grant can satisfy.The path-argument deny runs before the permission gate, so it holds even under --dangerously-skip-permissions. The shell prompt does not: that flag skips the gate, and with it the prompt.Path arguments. A tool call whose path argument names a sensitive file is denied. The denylist runs to 42 patterns, among them .env and its variants, .dev.vars, anything under .ssh or .gnupg, id_rsa and its ecdsa / ed25519 / dsa siblings, .pem / .p12 / .pfx certificates, .netrc, .npmrc, .pgpass, .htpasswd, .git-credentials, .aws/credentials, and Corbits Code’s own .corbits/settings.json. This covers reads, writes, edits, deletes, and searches pointed at one of those files. Template files like .env.example are exempt.Shell. A run_shell command is tokenized and every path-like token is checked against the same denylist, so cat .env, bun --env-file=.env run …, and FILE=.env cat $FILE all stop for an operator prompt rather than auto-running. No remembered grant can cover a secret-path shell command, so “Allow Always” never applies to one and each occurrence asks again. Detection here is token matching, not sandboxing. It defeats quoting and the common assignment and redirection forms, but a path assembled at runtime (for example F=.en; cat ${F}v) is not recognized as one.What the guard does not do. It keys on the path token, not on file contents, so it is not a content filter. A search scoped at a surrounding directory can still surface lines from a sensitive file inside it, such as a .pem under certs/, though a separate tool-result scrub redacts PEM private-key blocks and common API-key shapes before they reach the transcript. The guard also does not cover the Codex and xAI OAuth token files described on the configuration page: only the literal settings.json filename is matched. (secret path guard; credential scrubber)
A curated set of unrecoverable commands is blocked before it runs: filesystem creation (mkfs), raw disk writes (dd to a device), recursive deletes that target the filesystem root, your home directory, or a system tree, writes that clobber system paths like /etc, privilege escalation (sudo), power-state changes (shutdown, reboot), fork bombs, and piping a network download straight into a shell (curl … | bash). Like the secret guard, this cannot be overridden, not even with --dangerously-skip-permissions. Everyday destructive commands like rm -rf ./build aren’t hard-denied here; they go through the permission gate like any other consequential command.
Path arguments are resolved against the working directory; paths that escape it are blocked. After every write or edit, the file is re-read and compared to confirm the change actually landed.
Tools reached through an MCP server take a shorter path. They still go through the permission gate, and their results are still scrubbed for credential-shaped strings and truncated, but they do not pass the secret-path guard, the path-escape check, or the catastrophic-command deny described above. Weigh a third-party MCP server accordingly. (MCP permission path; credential scrubber) How much you approve by hand is yours to set. That setting never downgrades either guard: a secret-path shell command still stops for a prompt in auto mode, and the catastrophic-command guard is a hard deny that holds regardless.

​
Support

Help Center

Join hundreds of developers building with Corbits and speak with the team directly.