Only the latest minor line receives security patches. Upgrade to the current minor before reporting a vulnerability against an older line.
| Version | Supported |
|---|---|
| 6.6.x | Yes |
| < 6.6 | No |
We take security seriously. If you discover a vulnerability, please report it responsibly:
- GitHub Advisory (preferred): Use the "Report a Vulnerability" tab.
- Discord: Report it in our Discord: https://discord.gg/cTavsMgu
We will acknowledge your report within 6 business days and keep you informed of progress toward a fix.
Note: We do not accept AI-generated security reports. Submitting one will result in a ban from the project. Please ensure your report includes specific reproduction steps and demonstrates a real impact.
ax-code is an AI-powered coding assistant that runs locally on your machine. It provides an agent system with access to powerful tools including shell execution, file operations, and web access.
The runtime isolation default is workspace-write with network disabled. This is the default safe posture for local repository work: the agent can edit inside the workspace, but writes outside the workspace, protected-path writes, and network tools require an explicit boundary change.
ax-code includes a built-in execution isolation sandbox that restricts what the AI agent can access at the tool level. Three modes are available:
| Mode | Behavior |
|---|---|
| Workspace write (default) | Allows writes only inside the workspace; .git and .ax-code are always protected; network disabled by default |
| Read-only | Blocks all file mutations and shell commands |
| Full access | Disables isolation entirely |
Key properties:
- Default behavior — AX Code starts in
workspace-writeunless--sandbox,AX_CODE_ISOLATION_MODE, or config sets a different mode - Explicit unrestricted mode — use
full-accessonly when you intentionally want to disable isolation - Tool-level enforcement — all mutation tools (bash, edit, write, apply_patch) and network tools (webfetch, websearch, codesearch) check isolation policy before executing
- Protected paths —
.gitand.ax-codedirectories are always protected from writes, even in workspace-write mode - Escalation prompts — isolation violations present an approval dialog instead of silently failing; users can allow a blocked operation once without changing their config
- CLI control —
--sandbox read-only,--sandbox workspace-write,--sandbox full-access - Environment variable —
AX_CODE_ISOLATION_MODE
The isolation sandbox operates at the application layer (tool permission checks), not at the OS process layer. If you need OS-level isolation, run ax-code inside a Docker container or VM.
- Localhost only by default — the server binds to
127.0.0.1, inaccessible from the network - Password required for network access — binding to
0.0.0.0or any non-localhost address requiresAX_CODE_SERVER_PASSWORDto be set; the server refuses to start without it - Basic auth enforced — when
AX_CODE_SERVER_PASSWORDis set, HTTP Basic Auth is required on all API endpoints - CORS configurable — additional allowed origins can be specified via
--cors
Provider API keys are encrypted at rest using AES-256-GCM with PBKDF2 key derivation and stored in the local AX Code data directory (~/.local/share/ax-code/) with user-only file permissions (0600).
The encryption key is derived from local machine attributes (hostname, platform, architecture). This protects against casual offline disclosure (e.g., accidental file sharing) but does not protect against a determined attacker with access to the host. It is not equivalent to OS keychain or hardware-backed secret storage.
MCP OAuth tokens, client secrets, and account access/refresh tokens are also encrypted at rest using the same mechanism. Non-sensitive metadata (server URLs, expiry timestamps, email, account IDs) remains in plaintext.
The shell installer verifies downloaded GitHub release archives with minisign before extraction. The pinned AX Code release public key is:
RWS+dNbWPLZ6W9TH486c9zdH84NiiuFnm4VpVTRlXoMHClyQx/fY7W2A
The installer downloads the matching .minisig asset for the selected archive and fails closed when minisign is unavailable or verification fails. Set AX_CODE_SKIP_MINISIGN_VERIFY=1 only when you intentionally accept an unverifiable release download.
Maintainers should keep the minisign secret key encrypted. For local release signing on macOS, store the passphrase in Keychain instead of a plaintext file:
security add-generic-password -U -a ax-code-release -s ax-code-minisign -wRelease tooling reads that Keychain item automatically when AX_CODE_MINISIGN_PASSWORD is not set.
The tag-driven GitHub release workflow signs archives before upload. It requires these repository secrets:
AX_CODE_MINISIGN_SECRET_KEY_B64
AX_CODE_MINISIGN_PASSWORD
AX_CODE_MINISIGN_SECRET_KEY_B64 must be the base64-encoded contents of the
encrypted minisign.key minisign secret key. The workflow writes it to a
temporary 0600 key file, verifies the pinned public key, signs each release
archive, and uploads the matching .minisig assets with the archives.
| Effective date | Key ID | Public key | Status |
|---|---|---|---|
| 2026-06-16 | 5B7AB63CD6D674BE |
RWS+dNbWPLZ6W9TH486c9zdH84NiiuFnm4VpVTRlXoMHClyQx/fY7W2A |
Current |
| pre-2026-06-16 | 8138FAD32CAD95BA |
RWS6la0s0/o4gdFUZ0Bk/BkrnN8qC2CFOfLXVP5OtQTrvm1BQeOvXgao |
Rotated out |
The release signing key was rotated on 2026-06-16. The installer and release
workflow pin only the current key, so archives signed with the retired key will
fail signature verification. Historical release archives are re-signed with the
current key via script/resign-release-assets.ts so every published release
verifies against the pinned key without trusting the retired key.
To re-sign and re-upload an existing release's .minisig assets with the
current key:
bun run script/resign-release-assets.ts --tag v5.5.0 --key-dir ~/.minisign| Category | Examples |
|---|---|
| Sandbox bypass | Executing commands or writing files outside allowed boundaries |
| Authentication bypass | Circumventing AX_CODE_SERVER_PASSWORD in server mode |
| Key exfiltration | Extracting stored API keys without local machine access |
| Path traversal | Tools reading/writing outside the intended working directory |
| Command injection | Crafted input that executes arbitrary commands bypassing isolation |
| Dependency vulnerabilities | Known CVEs in bundled dependencies with a viable attack path |
| Category | Rationale |
|---|---|
| LLM provider data handling | Data sent to your configured provider is governed by their policies |
| MCP server behavior | External MCP servers you configure are outside our trust boundary |
| Malicious config files | Users control their own config; modifying it requires local access |
| Social engineering | Prompt injection via untrusted repos is a known LLM-agent limitation |
| OS-level sandbox escapes | The isolation sandbox operates at the application layer, not the OS process layer |
AX Code is designed for enterprise use with the following hardening features:
- Fine-grained Permissions: Agent-specific and pattern-based rulesets (
allow/deny/ask). Security agent defaults to read-only. Rules evaluated across project, agent, and approved lists. - Session Audit Trails: Every tool call, permission decision, and file change is recorded in SQLite with snapshots. Supports replay, fork, and export for compliance reviews.
- Deterministic Refactoring (DRE):
impact_analyze,refactor_plan, andrefactor_apply(shadow worktree + lint/typecheck/tests) provide auditable, reversible changes. - Credential Management: AES-256-GCM encryption for all keys/tokens. Per-directory isolation via
InstanceState. - Default Sandbox Enforcement: Application-level isolation with bash command parsing (tree-sitter). The runtime defaults to
workspace-writewith network disabled; protected paths (.git,.ax-code) apply in sandboxed modes. - Server Hardening: Localhost-only by default; password-protected remote access with Basic Auth.
- Code Intelligence & Scanning: Built-in secret/hardcode detection, dependency impact analysis.
For full enterprise governance (RBAC, policy-as-code, SIEM export, cryptographic audit), integrate with AX Trust (roadmap item).
See docs/sandbox.md for isolation configuration and runtime behavior.