Security at Codexa

• Generated and user code never runs inside the web application process.
• Secrets (environment variables, integration credentials) are encrypted at rest and never returned to the browser.
• Sessions use httpOnly cookies; session tokens are hashed at rest.
• Public and sensitive endpoints are rate limited.
• Security-relevant actions are written to an audit log.

Projects run in a separate runner service. The default driver executes each project as an unprivileged Linux user inside its own user, PID, mount, and network namespaces, with cgroup memory and process limits and a wall-clock timeout. Only allowlisted commands (install, build, test, type-check, start) can be executed; there is no arbitrary shell endpoint.

Operators can choose Docker or E2B drivers instead of the namespace driver. Previews are served through a host-based proxy so that a running project is never on the same origin as the Codexa application.

Project environment variables and workspace integration credentials are encrypted with an operator-held key before storage (encryptSecret) and decrypted only on the server when injected into a sandbox or used to call a provider. The UI shows masked values and the API never returns plaintext secrets.

Transport encryption (TLS) is the responsibility of the operator's deployment; the application sets secure cookie attributes when served over HTTPS.

• Passwords are hashed with a modern password hashing function; plaintext passwords are never stored or logged.
• Email verification and password reset use single-use, expiring tokens.
• Sessions are httpOnly, SameSite cookies (codexa_session); the stored session token is a hash, so a database read alone cannot be used to hijack a session.
• GitHub sign-in is available only when the operator configures OAuth; the OAuth state is checked on callback.
• Workspace roles (owner, admin, editor, viewer) are enforced on the server for every API route.

Login, signup, password reset, AI generation, and public forms are rate limited per IP or per workspace using a fixed-window limiter in PostgreSQL. Usage limits (AI requests and tokens, runtime minutes, deployments, storage) are enforced server-side per workspace. Abuse reports can be filed through support and are handled in the staff admin area.

Sign-ins, role changes, invitations, integration changes, deployments, and administrative actions are recorded with the acting user, workspace, and timestamp. Enterprise customers can request an export.

If you find a vulnerability, please report it through the vulnerability reporting form or email security@codexa.app. We do not run a paid bounty programme at this time. See the responsible disclosure policy for scope and what to expect.

Codexa secures the platform. You are responsible for the code you deploy, the data you put into it, the secrets you add, and for assessing whether a deployment meets your regulatory obligations. We make no compliance claims on your behalf.