What the agent can do & limits

The coding agent works through a fixed tool set — the same shape as a coding agent in your editor (read files, edit files, run commands), plus a few that are specific to building and deploying a live app. Knowing what it can and can't do helps you ask for the right thing.

Files

Tool	What it does
write_file	Create or fully overwrite a file (content taken verbatim).
edit_file	Surgical find-and-replace in an existing file.
multi_edit	Several edits to one file, applied atomically.
read_file	Read a file with line numbers (supports offset + limit).
list_files	List the app's file tree, with optional glob filtering.
delete_file	Remove a file.

Running & testing

Tool	What it does
bash	Run a shell command in a sandbox — navigation, linting, type-checking.
run_js	Run a self-contained JS snippet in an isolated sandbox to verify pure logic fast, without deploying.
verify	Deploy the current files and smoke-test them in Cloudflare's runtime.
run_api_tests	Run real HTTP requests (create → read-back → update → delete) against every /api route.
run_ui_tests	A real browser clicks through the main screens and checks elements update.
run_test_script	Write custom JS (WebSocket, SSE, uploads, multi-step flows) to test what the other runners can't.

Inspecting the live app

Tool	What it does
http_get / http_post	Call a path of the deployed app and see its real status + body.
query_db	Run a read-only SQL query against the live database.
db_write	Run a write SQL statement (seed data, a migration you forgot, a repair).
read_logs	See the app's recent server errors — including real user traffic.
render_screen	Screenshot a page in a real browser at phone / tablet / desktop widths.

App management

Tool	What it does
list_secrets / request_secret	See which secrets are configured (names only) or ask the user for one.
set_app_meta	Set the store listing (name, icon, description, category, features).
set_app_preview	Set the store preview screenshots.
generate_image	Generate an image for the app.
web_search	Look up current facts (e.g. a service's real API).
git_log / git_revert	Browse or revert files in a connected GitHub repo.
memory_write / memory_read	Persist preferences and conventions across your apps.

Connectors

Instead of hard-coding API keys, the agent can wire a connector — a pre-built integration whose credentials are stored as app secrets, never in source. Built-in connectors include Supabase, Firebase, Notion, Figma, Cloudinary, VNPay, PayOS, and MoMo; for anything else, the agent can research the service's real API and guide you through connecting it.

Limits and guardrails

These are the boundaries the agent works inside:

• Bare imports are not allowed in the backend — the Worker is a single self-contained script, so the agent uses relative imports of files it includes, and calls external APIs with fetch().
• Worker size budget — all static assets are inlined into one Worker script; the deploy enforces a compressed ceiling (by default ~9 MB), and the agent is warned as it approaches it. Large embedded data belongs in the database, KV, or R2, not inline in source.
• bash is sandboxed — no network access, destructive commands blocked, secret access blocked. Ordinary commands get a short timeout; heavy tooling (type-check, lint, build) gets a longer floor automatically.
• No open internet from test scripts — run_test_script runs against your app's own origin only.
• Test writes are non-destructive — http_post won't charge real money or send real bulk email while testing; a destructive db_write is not refused but comes back with an explicit warning.
• No silent success — the agent is expected to verify a change worked (tests, a build, a lint) before calling a turn done, and to flag flaky tests rather than claim a win on one green run.

Next steps

• How it works — the runtime behind these tools.
• Security & sandboxing — how isolation and secrets are enforced.
• Troubleshooting.