Dyad

The agent acts with the full authority of the logged-in user. The app's dev server, builds and package installs are started with a copy of Dyad's whole environment, so any credential in it is available to code the agent wrote. One path narrows this: end-to-end test runs strip the app's database credentials from the environment. Optional integrations add broad, long-lived credentials such as a Supabase management token and a GitHub token with repo and workflow scopes.

Each agent tool has a consent level, and a handful default to asking: adding packages, schema-changing or deleting SQL, reinstalling dependencies and every MCP tool call. The prompt shows the exact SQL or package list, though MCP arguments are cut at 500 characters. Writing, deleting and renaming files, restarting the app, building and running tests all default to running without approval, and restarting or building executes code the agent just wrote. Each turn is committed to git, so file changes can be rolled back, but anything the running code does on the machine cannot.

File tools resolve paths and symlinks and refuse anything outside the app folder, and reads open the resolved file and check it before reading. Package names are checked against strict npm name and version patterns, and outputs and file sizes are bounded. The weak points are reach rather than validation: by default the agent can write any file in the app and then run the app, build or tests, which executes whatever the app's scripts say. MCP tools get only schema validation.

The only sandbox on by default is a small scripting runtime used by one tool, which gets file and MCP access only through functions Dyad injects and has time and memory limits. Everything else that runs code does so directly on the host: the app's dev server, production builds, type checks, tests and package installs, all under the user's account with the inherited environment. An optional Docker runtime runs the dev server in a stock container with the app folder mounted and normal network access, but builds and installs still run on the host.

The agent reads content its user did not write, such as imported repositories, app console logs and MCP tool results, and nothing in code separates that content from the user's instructions. There is no taint tracking and no rule that forces approval once untrusted content has been read; the only defence is prompt wording. A hijacked session can write code and run it on the host without approval, which is enough both to send data anywhere and to make irreversible changes.

Each app's AI_RULES.md is read from the app folder on every turn and placed in the system prompt as authoritative project guidance, and the agent can edit that file without approval. An imported repository can therefore ship its own rules, and anything written there steers every later session in that app. Chat history from earlier conversations is also searchable by the agent. The file is versioned in the app's git history, so changes can be inspected and reverted by hand.

MCP servers are added by the user (a deep link only pre-fills a dialog) and run whatever command and arguments were entered, unpinned. Package installs through the dedicated tool ask first and are wrapped in a pinned Socket firewall that blocks known-malicious packages, falling back to an unscreened install with a warning when it can't be set up. Running or building the app installs and executes the packages its package.json lists without a prompt, as the build tool's own description acknowledges. Installed packages and MCP servers run as the user.

Provider keys and integration tokens are encrypted with the operating system's secure storage, falling back to plaintext only when it is unavailable. Values in .env files are redacted before file reads, grep, sandbox scripts and codebase context reach the model, and model-request logs record only metadata. Telemetry is opt-in. The gaps are the environment handed to app, build and install processes, unredacted build and log output, and chat transcripts stored unencrypted.

Every tool call is written into the chat message in Dyad's local database as it happens, including its arguments and result, and the full model message history is saved at the end of the turn. Each turn is also committed to the app's git repository. The record carries no separate actor or approver fields, approvals and denials are not clearly logged, and the database sits in the user's data folder where code running as the user could change it.

A turn stops after 100 tool steps by default (selectable from 25 to 200), builds are limited to three per turn, and builds, installs, shell commands and sandbox scripts have timeouts. There is no token or cost cap for a run beyond the free tier's message quota. Stopping a turn aborts the model stream and passes a cancel signal to tools, but the app's dev server keeps running, and code the agent runs on the host can modify Dyad's own settings.