Capsid runs application code in separate worker processes, but process isolation alone is not a complete security boundary. Whether it is suitable for running untrusted code depends on whether the strict sandbox, host capability limits, application permissions, network namespace/firewall, resource limits, and downstream gateway restrictions are all configured correctly at the same time.

The project is currently at 0.2.2 (C ABI v7); security fixes target the latest code line, and there is no commitment yet to long-term security maintenance for older versions. The first-party capsid-host is currently used for development, integration, and benchmarks; it is not a stable production deployment interface. The Linux strict sandbox is the v1 production isolation target; macOS native-dev, Windows native-dev, and any non-isolated mode must not be used to run untrusted code. For platform differences, see platform support overview.

The following are within the project's security boundary:

• Runtime/worker IPC, parsing, flow control, and lifecycle;
• capability policy, module gates, and egress network decisions;
• Linux seccomp, Landlock, rlimit, cgroup, and namespace integration;
• bundle, trusted bytecode, build identity, and signature verification;
• first-party host configuration, Admin API, release recovery, and credential checks.

TLS, external gateways, host firewalls, secret lifecycle, and OS hardening are not guaranteed by Capsid alone; however, defects at the interfaces between Capsid and these boundaries are still welcome.

Do not disclose details of unfixed vulnerabilities in public Issues, Discussions, Pull Requests, or benchmark artifacts.

Prefer GitHub's private vulnerability reporting. If that entry point is temporarily unavailable, create an Issue without technical details and ask the maintainers to establish a private contact channel.

Please include as much of the following as possible in your report:

• Affected commit, version, platform, and build options;
• Prerequisites, minimal reproduction steps, and actual impact;
• Whether an untrusted bundle, specific permissions, or host configuration is required;
• Crash, audit, sanitizer, or sandbox evidence, but no real secrets;
• Known mitigations and the coordinated disclosure timeline you expect.

After maintainers confirm the issue, they will coordinate reproduction, fix, regression tests, and disclosure. The project currently does not promise a fixed response SLA; please avoid disclosing exploit details publicly until a fix and a user migration window are ready.

• strict_sandbox is disabled by default; the default configuration can only run trusted code.
• Permissions must start from the smallest set; host limits must not use broad allow rules as a substitute for application-declared permissions.
• Egress networking must restrict hostname, resolved IP/CIDR, redirects, and OS network boundaries together.
• A worker may enter scheduling only after CAPSID_EVENT_READY.flags satisfies deployment requirements.
• QuickJS bytecode is not a safe input format; only load trusted artifacts generated by the exact same build and validated by the host.
• After protocol errors, worker exit, or synchronous CPU timeout, the worker must be removed and replaced.

For the complete deployment boundary, see architecture notes, platform support overview, capability policy, and Linux strict sandbox.