From base44
Connects your coding agent to a Base44 app sandbox over MCP for remote development. Covers sandbox tools, authentication, edit-preview-verify loop, and the 'Send to Coding Agent' button.
How this skill is triggered — by the user, by Claude, or both
Slash command
/base44:base44-remote-devThe summary Claude sees in its skill listing — used to decide when to auto-load this skill
<!--
Connect your own coding agent to a Base44 app's sandbox and develop in it directly — run commands, read and edit files, grep, list directories — while Base44 supplies the sandbox and you supply the agent and the LLM.
This works with any MCP-capable client. The examples use Claude Code.
Easiest start: in the Base44 app editor, click Send to Coding Agent. For a local agent it gives you a ready-to-paste prompt (which fetches a README and drives the sandbox over MCP or the
base44 sandboxCLI — Section 10); for the web it gives a prompt to paste into a claude.ai chat (with the Base44 MCP connector) plus an Open Claude button. The button is the discovery surface — the rest of this skill is the reference.
Two transports: web agents use claude.ai with the Base44 MCP connector (Sections 1–9) — note this is the regular claude.ai chat, not Claude Code on the web (
claude.ai/code), which runs in its own repo-backed sandbox. A local agent can connect that same MCP server, or drive the sandbox with thebase44 sandboxCLI (a Base44 CLI token, Section 10) — same tools, same behavior, same error codes; the CLI just exposes them under shorter command names (sandbox read,sandbox ls, …).
The Base44 MCP endpoint is:
https://app.base44.com/mcp
Register it with Claude Code (run from any folder):
claude mcp add --transport http base44 https://app.base44.com/mcp
Add --scope user if you want it available in every project rather than just
the current folder.
claude mcp add only writes the config — it does not authenticate yet.
Start Claude Code and open the MCP menu:
claude
then, inside Claude Code:
/mcp
Select base44 → Authenticate. A browser opens for the Base44 OAuth
flow (PKCE) — log in and approve. When it succeeds, /mcp shows base44 as
connected and lists its tools.
Pure-CLI / headless clients that can't open a browser use the OAuth device
flow (/oauth/device/code) instead — request a code, approve it in a browser
on another device, and the client receives the token.
| Tools | Required scope |
|---|---|
read_file, grep, list_directory, get_app_preview_url, get_app_status, list_user_apps | apps:read (granted by default) |
write_file, edit_file, run_command, create_checkpoint | sandbox:write |
sandbox:write is not granted by default — shell and file mutation
require it explicitly. If the read tools work but the mutating ones return
NOT_AUTHORIZED, your token is missing sandbox:write; reconnect and grant
sandbox access (the device flow can request it explicitly).
Every tool takes a required appId. Find your apps with list_user_apps, then
pin the id in your requests so the agent passes it on every call.
Start read-only to build a mental model before changing anything:
Using the base44 tools on appId <APP_ID>:
1. list_directory on the app root (recursive, depth 2)
2. read_file src/App.jsx and src/pages.config.js
3. grep for the component I want to change
Summarize the structure before editing.
Cold start: if the app has no running sandbox, the first tool call transparently brings one up from your last commit — it just takes a bit longer. Subsequent calls are fast.
CLI names: over the
base44 sandboxCLI (Section 10) these read tools arelist_directory→sandbox ls,read_file→sandbox read, andgrep→sandbox grep.
edit_file (sandbox edit in the CLI) — preferred for changing existing files. Provide exact
old_text→new_text edits. Each old_text must be unique in the file
unless you set replace_all. All edits in a call apply atomically
(all-or-nothing) and you get a unified diff back. Pass dry_run: true to
preview the diff without writing.write_file (sandbox write in the CLI) — for creating new files. To overwrite an existing file you
must pass overwrite: true (it never silently clobbers).run_command (sandbox run in the CLI) — run any bash command in the sandbox (build, install,
scaffolding, codemods). The working directory defaults to the app root; cd
does not persist across calls, so use the cwd parameter or chain commands
(cd sub && cmd). Timeout defaults to 120s (max 600s); output is capped at
~1 MB.create_checkpoint (sandbox checkpoint in the CLI) — save a named
restore point the user can later roll back to. Takes an optional name
(message/title; auto-generated if omitted). Any pending changes are flushed
and committed first so the checkpoint anchors to your latest code; it then
returns the checkpoint id, name, and git commit hash. Use it to mark a
known-good state before or after a chunk of edits. (If a recent auto-commit
can't be confirmed durable yet, it refuses with the retryable
COMMIT_FLUSH_PENDING rather than checkpoint stale state — retry shortly.)Example:
On appId <APP_ID>, use edit_file to change the homepage heading in
src/pages/Home.jsx from "Welcome" to "Welcome back". Show me the diff first
with dry_run, then apply it.
There is no live log-streaming tool, but you can close the feedback loop:
get_app_preview_url brings up the dev server and returns
the preview URL. Vite HMR reflects your edits as you make them.get_app_status returns ready / processing / error.run_command:
npm run build # bundler/compile errors
npx tsc --noEmit # type errors
npm run lint # lint errors
/tmp/vite.log. Tail it via run_command to see HMR/compile errors:
tail -c 32000 /tmp/vite.log
(This is outside the app tree, so it's only reachable through run_command,
not the file tools — and therefore needs sandbox:write.)A solid loop: edit_file → npm run build (or tail /tmp/vite.log) → fix any
errors → get_app_preview_url to eyeball it.
Browser-runtime errors (a component that compiles but throws on render, a failing client API call) appear in the browser console, not in
/tmp/vite.log. Open the preview URL to catch those.
You don't need to "save." Every mutating call schedules a debounced auto-commit (~5 seconds): the change is committed and pushed to Base44's code storage, so it:
Practical implications:
You and the in-app Base44 builder can't mutate the same app at once:
BUILDER_BUSY. Poll get_app_status and retry once it's ready. Read-only
tools still work during a build.PATH_OUTSIDE_SANDBOX)..agents/ is off-limits to file tools (PROTECTED_PATH) — it holds
agent-managed config and secrets (.agents/.env). Don't try to read or edit
it through the file tools.RATE_LIMITED, slow down.delete_file isn't a dedicated tool — delete via run_command rm.NOT_AUTHORIZED (missing scope/flag) · APP_NOT_FOUND (wrong id or no access)
· PATH_OUTSIDE_SANDBOX · PROTECTED_PATH · NOT_FOUND · BINARY_FILE ·
EDIT_TEXT_NOT_FOUND · EDIT_TEXT_NOT_UNIQUE (make old_text unique or use
replace_all) · OVERWRITE_NOT_ALLOWED (pass overwrite: true) · TIMEOUT ·
OUTPUT_TRUNCATED · BUILDER_BUSY ·
COMMIT_FLUSH_PENDING (a pending auto-commit isn't durable yet; retry shortly —
e.g. on create_checkpoint) · RATE_LIMITED · BACKEND_ERROR.
Messages are written so the agent can self-correct — read them and adjust.
list_directory + read_file (or grep)
pass costs little and dramatically improves edit accuracy.dry_run on edit_file to confirm the diff before committing to a
change, especially for multi-edit calls.edit_file over write_file for existing files — surgical edits
avoid clobbering and produce a reviewable diff.read_file's offset/limit on large files
instead of pulling the whole thing into context./tmp/vite.log before guessing —
it usually names the exact file and line.create_checkpoint (sandbox checkpoint)
to mark a restore point before or after a risky chunk of edits — it flushes
pending changes first, so the user can always roll back to that point.base44 sandbox CLIIf your agent runs on your machine, it can drive the same sandbox through the Base44 CLI instead of MCP, authenticating with the Base44 CLI instead of OAuth. Same tools, same behavior, same error codes (Section 8) — only the surface and auth differ.
Auth. Log in with the Base44 CLI (base44 login) — the same credential used for
base44 functions deploy. Like the projectless base44 connectors commands, the sandbox
subcommands resolve the app id from --app-id, then BASE44_APP_ID, then a local .app.jsonc;
no config.jsonc is required.
Command names. The CLI exposes each sandbox tool under a shorter name:
| MCP tool | CLI command |
|---|---|
list_directory | base44 sandbox ls |
read_file | base44 sandbox read |
write_file | base44 sandbox write |
edit_file | base44 sandbox edit |
run_command | base44 sandbox run |
grep | base44 sandbox grep |
create_checkpoint | base44 sandbox checkpoint |
npx base44 sandbox read --app-id <APP_ID> src/App.jsx
base44 sandbox checkpoint takes an optional --name (message/title) and saves a restore point:
npx base44 sandbox checkpoint --app-id <APP_ID> --name "before refactor"
Hand an agent the full reference for a specific app (instructions, public, no auth needed to fetch):
https://app.base44.com/api/sandbox/<APP_ID>/local-agent/readme.md
(The cloud/MCP equivalent is .../api/sandbox/<APP_ID>/claude-web/readme.md.)
Everything else in this skill — the edit→preview→verify loop (Section 5), persistence (Section 6), concurrency (Section 7), and guardrails (Section 8) — applies identically; only the surface and auth differ.
Beyond the sandbox file/shell tools, the Base44 MCP server exposes two tools for managing a
third-party OAuth connector (Google Calendar, Gmail, Slack, …) on an app. They don't touch the
sandbox filesystem — they operate on the app's connector state directly. Both take appId.
| Tool | Scope | Purpose |
|---|---|---|
list_connectors | apps:read | List the app's connectors. With no integrationTypes, returns the full catalog (name, description, connected?, and — if connected — status and granted scopes). Pass integrationTypes for detail on specific ones. |
initiate_connector_connection | apps:write | Connect (or re-scope) a connector. Inputs: appId, integrationType, scopes, optional connectionConfig. |
Two semantics to get right:
initiate_connector_connection sets the connector
to exactly the scopes you pass. Omitted scopes are removed and the user is re-prompted to
consent. Always call list_connectors first, then pass the complete desired set (existing
scopes you want to keep plus any new ones).already_authorized: true (nothing to do) or a
redirect_url the user must open in a browser to sign in and consent — you can't complete it
yourself. After they finish, call list_connectors again to verify and read the granted
scopes (a provider may grant fewer than requested).These need only apps:read / apps:write — not sandbox:write. Over the CLI surface
(Section 10), the equivalent is the projectless base44 connectors commands
(list-available, initiate --integration-type <t> --scopes <s...> --app-id <id>, pull), which
print the same authorization URL.
npx claudepluginhub base44/skills --plugin base44-sandboxDevelop Base44 apps remotely inside Base44's cloud sandbox without local checkout. Writing resource files auto-syncs backend functions, entities, and agents. Also covers connector setup.
Leverages OpenAI Codex/GPT models for autonomous code implementation, reviews, and sandboxed task execution. Triggers on 'codex', 'use gpt', 'full-auto' etc.
Maximizes productivity with Anthropic's Claude Code CLI: shortcuts, hooks, MCPs, advanced configuration, workflows, CLAUDE.md, memory, sub-agents, permissions, and ecosystem integrations. Activate for configuring Claude Code, creating hooks, optimizing CLAUDE.md, using MCPs, resolving CLI errors, or advanced workflows.