Skip to content

How it works

From a prompt to a deployed application, step by step.

Codexa runs a bounded loop: plan, generate, validate, run, ship. Every step is visible, every change is snapshotted, and every run can be reverted.

  1. Step 1: Plan

    The agent reads your prompt and the project files, then writes a short plan of the files it will create or change.

  2. Step 2: Generate

    It edits real files with tools (read, write, rename, delete). Every change is recorded, and a snapshot is taken first.

  3. Step 3: Validate

    Type-check, build, and tests run in an isolated sandbox. Errors are read back and repaired, bounded to two attempts.

  4. Step 4: Run

    Start a preview in the sandbox with streamed logs, viewport controls, and a share link.

  5. Step 5: Ship

    Deploy to Codexa static hosting or Vercel, keep deployment history, and roll back in one click.

Requires an AI provider

AI features require an Anthropic or OpenAI API key configured by the operator of your Codexa instance. When no key is configured the agent shows an explicit "not configured" state instead of pretending to work.

What you see while it runs

Interface previewA static illustration of the Codexa workspace layout, built from the product's UI components. Not a screenshot of a live session.

1. Plan

The agent receives your prompt together with a listing of the project files and the contents of the files it decides to read. It writes a short plan: which files it will create or change and why. In Ask mode it stops here and answers without editing.

Before any edit, Codexa creates a snapshot of the project. That snapshot is what the per-file diff and the revert action compare against.

2. Generate

Edits happen through tools (read, write, rename, delete) against your real project files in PostgreSQL. Each tool call and each file change is streamed to the browser as it happens, so you can follow along or cancel.

  • Starter templates: React + Vite + TypeScript + Tailwind, static HTML/CSS/JS, Node + Express.
  • Imported GitHub repositories are edited in place.
  • Usage (requests and tokens) is recorded per run and counted against your plan; see credits.

3. Validate

The changed project is synced into an isolated sandbox where type-check, build, and tests run as allowlisted commands. Output is read back by the agent. If there are errors it attempts a repair, at most twice, and then hands control back to you with the errors visible.

4. Run

Start a preview in the same sandbox. The runner service executes your project as an unprivileged user inside Linux namespaces with memory and process limits; a host-based proxy serves it at a preview hostname. Logs stream to the workspace and you can switch viewports to check responsive layouts.

5. Ship

Deploy to Codexa static hosting: the build runs in the sandbox, the output is served at a subdomain, and every deployment stays in history so you can roll back. The Vercel adapter is available when a token is configured. Custom domains get CNAME instructions today; verification is planned.

Frequently asked questions

Can I stop a run half way?

Yes. Runs stream their progress and can be cancelled. Whatever was changed up to that point is visible in the diff and can be reverted.

What if validation keeps failing?

After two repair attempts the agent stops and shows the errors. You can fix them in the editor, ask the agent in Fix mode with a specific error, or revert the run.

Does the agent run my code on its own?

Only allowlisted commands (install, build, test, type-check) in the sandbox. Starting the preview is a separate action you trigger.

Where is my code stored?

Project files are stored in PostgreSQL. Snapshots are stored alongside them. You can export to GitHub whenever GitHub OAuth is configured.

Start building with Codexa

Free plan, no card required. Describe your idea and get a real project you can edit, run, and deploy.