Build with Codex
Build a Reboot app with Codex and the Reboot plugin. You describe what you want, approve the design, and Codex scaffolds the whole project: API definition, backend servicers, frontend, sign-in, tests, and local development setup.
Install the Reboot plugin
The plugin bundles everything Reboot needs, so the only prerequisite is Codex itself, installed and authenticated.
- Quick install
- Manual install
Install the Reboot plugin for Codex with a single command:
curl -fsSL https://reboot.dev/install.sh | bash
The installer detects Codex, registers the Reboot plugin marketplace, installs the plugin, enables Codex hooks, and pre-installs the pinned tool shims used by the skill.
The installer currently asks to disable Codex's sandbox globally by
writing sandbox_mode = "danger-full-access" into
~/.codex/config.toml. This is a temporary workaround for an upstream
Codex issue that breaks Python asyncio cross-thread wakeups inside the
sandbox. Reboot's main commands (rbt generate, rbt dev run, and
related commands) rely on that asyncio behavior.
If you accept the prompt, the installer tags the setting with a
# reboot-plugin (managed) comment so it is easy to find and remove
later. If you decline, the Codex install is skipped because the
plugin's main commands will not work reliably under the current
sandbox behavior.
Restart Codex after installation so the new plugin, skills, hooks, and PATH configuration are loaded.
Register the Reboot plugin marketplace and install the plugin yourself:
codex plugin marketplace add reboot-dev/reboot-plugin
codex plugin add reboot@reboot-plugin
Then add the required Codex settings to ~/.codex/config.toml. Codex
prints the plugin install path in codex plugin list; use it to build
the PATH entry for your machine:
REBOOT_PLUGIN_ROOT="$(codex plugin list \
| awk '$1 == "reboot@reboot-plugin" {print $NF; exit}')"
printf 'features.hooks = true\n'
printf 'shell_environment_policy.set.PATH = "%s/bin:%s"\n' \
"$REBOOT_PLUGIN_ROOT" "$PATH"
printf 'sandbox_mode = "danger-full-access"\n'
Copy the output into ~/.codex/config.toml, at the top of the
file (dotted keys pasted below a [table] header would become part of
that table). It should look like this, with your actual plugin path:
features.hooks = true
shell_environment_policy.set.PATH = "/path/from/codex/plugin/list/bin:/your/existing/path"
sandbox_mode = "danger-full-access"
TOML forbids defining the same key or table twice, and Codex refuses
to start on such a config ("duplicate key"). If your config already
has a [features] or [shell_environment_policy] table, or already
sets sandbox_mode, set the values inside your existing tables
instead of pasting the dotted keys above — e.g. add hooks = true
under your [features] table.
Restart Codex after changing the config.
Describe your app
In Codex you do not need a slash command. Start from a normal prompt:
Build me a Reboot todo-list app I can use from a browser and from Claude and ChatGPT
That prompt gets you one backend with two front doors: a React web app
you open in a browser, and an MCP UI that
Claude and ChatGPT can drive as tools — sharing one set of todos and
one signed-in User per person.
Codex picks the right Reboot skill from your description. The one thing it will not guess from the subject matter is where the app lives, so say it:
| You say | You get |
|---|---|
| "web app", "website", "SPA", "in the browser", a URL | A web app: a React frontend on its own origin. |
| "MCP", "in Claude", "in ChatGPT", "MCP UI" | An MCP UI: tools and UI methods over MCP. |
| Both, as above | One backend serving both frontends, with one User per person. |
The skills scaffold web frontends and MCP UIs. A React Native app (alpha) is added by hand.
If your description doesn't say, it asks first.
What it does before it writes code
The builder settles the design first. It will:
- Analyze your description and propose a state model.
- Map out the types, methods, the pages or UIs the frontend needs, and how users sign in.
- State that design back to you — so you can redirect it before the code exists.
Then it scaffolds the project, builds it, writes and runs backend tests, and starts the app.
The skills scaffold a Python backend. If you want a TypeScript backend, follow the hand-written TypeScript guide instead — but note that TypeScript backend support is in alpha.
What gets created
A complete Reboot project. The most relevant files:
my-app/
├── .rbtrc # Reboot CLI config
├── pyproject.toml # Python deps (uv)
├── api/
│ └── my_app/v1/
│ └── my_app.py # API definition (Pydantic)
├── backend/
│ ├── api/ # Generated Python bindings
│ ├── src/
│ │ ├── main.py # Application entrypoint, including `oauth=`
│ │ ├── example_prompts.py # MCP UIs: setup-wizard prompts
│ │ └── servicers/
│ │ └── my_app.py # Servicer implementations
│ └── tests/
│ └── my_app_test.py # Backend behavior tests
└── frontend/
├── package.json
├── build.mjs # Discovers + builds every UI
├── vite.config.ts # Vite dev server + build config
├── index.css # Theme variables
├── api/ # Generated React bindings
├── web/ # The browser SPA
│ ├── index.html
│ ├── .env.development # VITE_REBOOT_URL=http://localhost:9991
│ └── src/
│ ├── main.tsx # RebootClientProvider entry
│ └── App.tsx # Routes + top-level component
└── mcp/ # MCP UIs: one directory per `UI` method
└── my-ui/
├── index.html
├── main.tsx
└── App.tsx
Reading the code it wrote
| File | What it is | Learn more |
|---|---|---|
api/my_app/v1/my_app.py | Your API: one durable state type per entity, each with its methods, declared with Pydantic. | Define your API |
backend/src/servicers/ | The code behind those methods. | Implement your API |
backend/src/main.py | Constructs the Application and passes oauth=, so people can sign in and Reboot auto-constructs their User. | Users and sign-in |
frontend/api/ | Typed React hooks generated from your API, shared by every frontend. | Call your API from React |
frontend/web/ | The browser app. | Web apps |
frontend/mcp/ | One React app per UI method, rendered inside the MCP client. | MCP UIs |
tests/ | Feature files: the scenarios that specify and test the app, run against an in-process Reboot. | Features |
In development the sign-in flow uses Development(), a fake account
picker, so you can sign in as any of a handful of identities without
registering a provider anywhere. Before you deploy, pick a
real provider.
Test and run
Codex writes backend unit tests covering your app's user stories and runs them before handing the app off — they help make sure the app works, and keeps working.
Once the tests pass it starts everything the app needs:
- the Reboot backend (
rbt dev run), serving your API athttp://localhost:9991; - the Vite dev server, on
http://localhost:4444; and - for MCP UIs, a Cloudflare quick tunnel, so cloud-hosted MCP clients can reach your machine.
For a web app it gives you http://localhost:4444 to open. Click Sign in,
pick a Development identity, and Reboot
auto-constructs your User.
For an MCP UI it opens the setup wizard at
http://localhost:9991 — a page your app serves that walks you
through connecting Claude, ChatGPT, or an inspector, and suggests
example prompts.
Iterate
The same skill modifies an existing app:
Add due dates to todos, and a filter for what's overdue.
Codex reads the current Reboot project, proposes a plan, waits for your approval, then updates the API, servicers, React pages, and tests.
Run it again later
Coming back to the project later:
Run my Reboot app in ./my-app
Or just say "Run this Reboot app" from the project directory.
Next steps
- Build with Claude Code — the equivalent agent-driven workflow for Claude Code.
- Python backend and React frontend — build it by hand, to see every file.
- Users and sign-in — what the
Usertype the skill generated is doing. - Call your API from React — the full reference for the generated hooks.
- Examples — more apps to explore.
- Deploy to Reboot Cloud — ship it with
rbt cloud up. - Join the Discord — ask questions and share what you're building!