Security & Secrets
This page explains where devkit protects you and where it cannot. An agent session is not an OS security boundary.
What the signature protects
A release is activated only after its signature and checksum pass; a failed check keeps the previous version (how it works). Hooks then run with your shell privileges, so a validly signed but malicious payload could act as you: the signature proves who released it, not what an approved release does.
Credential protection
Use every control that applies:
| Control | Requirement and limit |
|---|---|
| Claude permissions | permissions.deny blocks selected reads and tool calls. |
| Sandbox credentials | In user or managed settings.json, give sandbox.credentials explicit files and envVars entries with a mode. A bare true protects nothing; mask needs sandbox.network.tlsTerminate. |
| File permissions | Keep live .env files at mode 600. This limits other OS accounts, not an agent running as you. |
Only configured paths and variables are protected; devkit does not inspect a project's secret setup. Never paste a credential into the chat; obtain and store it outside the transcript.
Commit and push checks
/commitruns gitleaks on the staged diff when it is installed; a finding stops the commit, and a missing gitleaks is reported as "not scanned"./commitstages only files changed in this session, nevergit add -A,.or-u.- The push gate warns about shell syntax and shellcheck errors in the pushed range and about spec lifecycle defects. It does not block;
OD_SKIP_PUSH_GATE=1disables it.
Sensitive actions
Shared rules require your approval for destructive, external, irreversible, credential-sensitive or scope-widening actions. Disabling the sandbox for a command needs explicit approval and an explanation of what was blocked.
What devkit sends home after a session is on the telemetry page.