Build one with the Builder

Describe the tool you want in plain language. Review what Wrengle built. Load it and try it. Ask for changes until it's right — no code required.

Open Plugin Builder from any New tab (+) menu or the command palette. It's a workspace tab: your chat sits on one side and the generated preview sits on the other, so you can read your prompt and see the result at the same time. Build progress shows up as short status cards in the chat — you don't need to watch a build log to know what's happening. Assistant replies use the same GitHub Flavored Markdown rendering as the Assistant panel, while your submitted prompts preserve their line breaks.

Drag the divider between the conversation and preview to resize them, or focus it with Tab and use the arrow keys. In a narrow pane, the preview stacks below the conversation and the divider adjusts their heights. Wrengle remembers each layout's sizes on this device. Resizing keeps your prompt and running preview in place.

The prompt field is the same advanced composer used by Assistant and Inline Assist. It keeps a Builder-owned draft and latest pending turn, while reusing the exact Run with catalog and permission-intent UI. Changing the Builder's route does not close or reroute the conversation in the Assistant panel. Enter sends, Shift+Enter adds a line, and input-method composition never sends accidentally. Focus the field to dictate an editable prompt; dictation never auto-sends it.

Each Builder project keeps its own unsent text, images, selected note context, route, and permission intent while you move between projects in the current app session. Returning to a project restores that complete draft. This cache is memory-only: restarting Wrengle, switching vaults, or deleting the project clears the affected drafts. Each draft still allows up to four images, 5 MiB per image and 20 MiB total; all cached Builder drafts and pending turns share a 100 MiB session limit. If returning a full pending turn would exceed a newer draft's image limit, Wrengle keeps the pending turn's images first and reports which newer images were left out. A cached route that is no longer available is cleared from that draft so the next available route you choose can be retained. An approved coding agent that was newly added or re-added stays unavailable until you explicitly select it from a Run with picker. Selecting it in Builder acknowledges that fence without changing the Assistant panel's route.

Builder also recognizes /new, /retry, /preview, and /stop. The command menu explains each action before it runs. Only one pending follow-up is kept: sending another replaces it. That slot retains the complete turn, including its selected route, permission intent, note attachments, and images. Stopping a live build moves the pending turn back into the editable draft instead of discarding it. Removing the pending-turn indicator does the same. If the vault changes, Wrengle discards a pending Builder turn from the old vault rather than restoring stale note authority into the new one.

Use Add context or type @ to search for one or more notes. Authority comes only from choosing a result: text that merely looks like a note path grants nothing. Each chosen note is an exact, turn-scoped Resource attachment bound to the open vault. Removing its visible token or context chip removes that authority too.

You can also attach, paste, or drop up to four PNG, JPEG, or WebP images, with the same size limits as Assistant. Images can be the whole prompt. On a compatible route, Wrengle normalizes them natively before the selected model or external agent sees them, and stages content-addressed copies as managed assets for the draft the Builder creates. On an incompatible route the complete draft is retained so you can switch routes or remove the images. Raw renderer files and image bytes are not written into the Builder conversation.

The Plugin Builder prompt accepts dictation on both the first-run screen and an existing project's chat. Focus it, then use Dictate, Hold to Dictate, or the voice shortcut. Dictated words stay in the editable draft and are never sent to the Builder model automatically; they follow the disclosure beside the prompt only when you choose Send or press Enter. Dictation's separate speech and Light edit routes can use cloud providers before the Builder prompt is sent; see Voice Control and AI & privacy. Free-text answers inside a Builder question card remain typing-only.

Under the hood, Plugin Builder works the way a person would: it looks at the shape of your workspace, asks you a question when it genuinely can't decide, builds a version, checks it, reads back what went wrong, and tries again. You watch that happen live in the chat. Nothing installs until you choose Add to workspace for a new plugin or Update for an existing one.

Sign in to your coding agent

Plugin Builder does not keep a second coding-agent login inside its scratch workspace. The current shared-auth route is Claude Code 0.70.0. Assistant and Builder reuse the same app-scoped secure-store identity, so an existing Assistant sign-in also works in Builder; the Keychain discovery fix does not require another login. If you have not signed in since moving to the app-scoped identity, complete one fresh Claude account sign-in from Assistant or choose Sign in in Builder. The account and subscription are shared without copying the credential into the Builder draft, scratch files, environment, or generated plugin.

The reviewed Claude runtime preserves native HOME for macOS Keychain discovery. Its CLAUDE_CONFIG_DIR, workspace, XDG directories, and temporary directories remain in fresh Builder scratch for each contained run. It does not inherit ANTHROPIC_API_KEY, Gemini or Google API keys, Application Default Credentials, service-account paths, OPENAI_API_KEY, or your ordinary CLI configuration. Gemini CLI and Codex return a typed unsupported result in Builder and remain available only in Assistant until their exact adapters can meet the same credential-isolation and MCP-only contract.

What it can build

Plugin Builder builds two kinds of local tool:

• Static custom views — a screen that displays content, with no saved data of its own.
• Offline feature apps — a screen that also remembers things between visits, such as a list you build up or settings you set once.

Offline feature apps can use window.wrengle.state.get, window.wrengle.state.set, and window.wrengle.state.delete to read, write, and remove their own saved values. Your draft declares which value keys it needs, and Wrengle checks the generated code against that list before Add to workspace or Update is enabled. Once installed, the app can only touch the keys it declared. Generated apps must use these host state helpers for saved data; browser storage such as localStorage, sessionStorage, and indexedDB is not supported.

Offline feature apps can use state.list and state.clear too, but only over the keys they declared and the values they saved themselves. You can still clear an app's saved data from Plugin Builder's own menu.

An app that asks for no workspace access cannot read or write your notes, projects, blocks, meetings, workflows, files, or settings. No app Plugin Builder makes can reach the network, use secrets, run shell commands, or call generated WASM actions. Everything else it does stays inside its own tab and its own saved data.

A habit tracker or another app that only saves its own data can run and be tested without reading your notes. It does not need a dashboard data source or note permission just to start.

Reading your notes is possible, and you decide. Plugin Builder can always see the shape of your workspace — folder names, how many notes are in each, the tags and note fields you use. That is names and counts only, never a word of note content, and it needs no permission.

Reading actual note content is a separate, explicit yes. Under Ask me, the first broad list, search, or read request opens a host-written permission card; your answer covers the rest of that conversation and nothing more. Auto approve and Full access do not mint that broad grant: without an earlier explicit grant in the same conversation and vault, they refuse the request.

An exact note you attach in the composer is narrower: it grants only that selected path to that submitted turn. It does not silently turn on the broader conversation-wide list, search, or read grant. Auto approve and Full access can approve other eligible Builder actions without pausing; they do not turn a typed path into an attachment or remove the vault-epoch checks.

A plugin it builds can also propose changes to your notes. A proposal is never applied on its own — you see exactly what would change and approve it, the same rule every other plugin follows.

How a build happens

Plugin Builder runs a short back-and-forth with your AI provider rather than a single request. Each round it can look something up, write a version of your app, check that version, or ask you something — and each round shows up in the chat as it happens: a line of what it's doing, a card per step, and a heading like Attempt 2 — fixed 3 issues when it takes another pass at a problem it found.

It remembers what you already said. Every message in the conversation, yours and its own, goes with the next round, so "make the flames orange" lands on the app you have been building rather than on a blank page.

It will ask you a question when two reasonable designs are both defensible and it cannot pick without you. Questions are written in plain language, with buttons for the likely answers and a box if none of them fit. It may ask at most four times in one build, and the question card tells you which one you are on.

Stop building first requests cooperative cancellation and preserves the visible stopping state while the in-flight round unwinds. If an external agent does not stop, the same control becomes Force stop, which closes its registered process tree. Stopping a new build discards its unfinished work. Stopping Review preview keeps the original draft available and discards only new repair attempts from the stopped run.

The built-in Builder loop gets a fixed number of rounds, and progress has to be real: if a round doesn't fix more than it breaks, Plugin Builder stops and tells you plainly rather than burning through your provider quota. External ACP agents are instead capped at 32 admitted Builder tool calls. Their private provider/model turns are not visible to Wrengle, so the host also enforces an overall deadline but cannot report those private turns as Builder rounds.

Checks and a test run happen inside the loop, so the builder sees its own mistakes and fixes them before you review anything. It can actually run the app it just wrote, in the preview beside the chat, and read the result back to fix its own work. What you apply is verified to match what you reviewed, and only installs or replaces the plugin after you choose Add to workspace or Update.

Once applied, the plugin view opens as a workspace tab. Later, reopen it from the command palette as Open <view label>, listed with the plugin's name so you can tell it apart from others.

Appearance and visual review

Generated plugins use your active Wrengle colour palette, including custom themes. Surfaces, text, borders, and accents use Wrengle's theme variables and update when you change appearance. Each plugin can still have its own layout, typography, spacing, and controls.

Before installation, the selected builder model reviews a screenshot of the rendered plugin for readable text and controls, palette consistency, clipping, overlap, and visual hierarchy. It receives the runtime test findings as well. When it finds problems, it changes the plugin and reviews a fresh screenshot. A build allows up to six completed visual reviews and five visual repair attempts within its overall limit of 32 model rounds or admitted external-agent Builder tool calls. The builder checks the requested behavior, readable text and controls, palette consistency, clipping, overlap, and layout. It repairs actionable findings and reviews a fresh screenshot after each change. It finishes early once the current preview passes all checks; it does not use the remaining attempts unnecessarily or skip review because the model says the build is done.

Wrengle automatically shares preview screenshots with the selected model or coding agent during the active build and its visual repairs, without a separate approval prompt. The preview shows a notice about screenshot sharing. A screenshot can include notes, selected text, and saved plugin data displayed in the preview. Wrengle captures only the visible plugin area; keep its preview open and unobstructed during review.

Visual review requires macOS and an image-capable route. Wrengle AI currently accepts text only, so choose a compatible direct provider or supported coding agent. Wrengle never changes the destination automatically or treats unavailable image review as a pass. Review covers the displayed theme and preview size; it is not a guarantee about every possible screen or state.

A changed plugin needs another review. New and updated plugins, including unfinished builds resumed from an older version of Wrengle, cannot be installed without a current passing review. Plugins already installed continue working. If an unfinished preview is missing a review, or its review expired after reopening, resizing, or changing the theme, choose Review preview beside its installation explanation. This continues the existing draft with the selected model and current permissions, including automatic repairs when needed. It preserves your unsent message and attachments. The original draft remains available if review is stopped or fails, and repairs carry forward its saved data and assets. Wrengle saves review findings and metadata, not screenshot bytes in its conversation history or generated plugin assets. The selected provider or external agent's own data handling still applies; see AI and privacy.

When a build can't finish

Plugin Builder says so plainly rather than pretending. A build ends early when it uses up its built-in rounds or external tool-call budget, when it stops making progress — the same problems still open after another attempt — or when you stop it yourself. Rejected attempts to write a plugin also count toward the no-progress limit, so repeated validation failures end the build instead of prompting continued retries. The last successfully generated version is preserved.

If a build fails after writing a recoverable version, that version stays available for review alongside the failure message. You can describe what to change and send another message to retry. An unfinished or failed test still blocks installation. If Wrengle cannot start the preview test, granting note access is not a workaround.

The preview explains why Add to workspace or Update is unavailable. Choose Needs a change to inspect the check findings. A working preview can still need review before installation. Review preview retries review and repair explicitly; reopening a draft does not start another model run. If capture or image review is unavailable, permissions are refused, or the run reaches its limits, the builder reports the remaining blocker instead of claiming success.

When a credential check rejects generated code, its explanation identifies the relevant description field or HTML source line and the kind of collection it found. Ordinary text fields, clipboard helpers, and explanatory mentions of credentials are allowed; fields or requests that collect credentials or regulated personal data are still refused. A privacy disclaimer does not make a prohibited field acceptable. If generated JavaScript is too large or complex to validate, Builder returns an analysis-limit explanation and asks the agent to simplify it.

Pomodoro timers and other apps that track focus or study sessions are supported. Their session counts are ordinary app data. Requests to store authentication sessions, session IDs, cookies, or tokens are still refused.

External coding agent authentication can fail because its shared account sign-in is missing, inaccessible, unsupported, or no longer accepted when generation begins, even after its session opened successfully. An unknown adapter version, changed executable, or unavailable host-enforced MCP-only policy fails the same way. Plugin Builder stops before sending the prompt and without creating or installing a generated draft. It restores the complete editable submission and never automatically resends or retries it. For a supported authentication failure, choose Sign in in Builder and select the account method. Complete the terminal or browser login, then explicitly send the build again. The login card targets the failed build's agent even if you have since changed the agent picker. It uses a separate recovery session with no conversation history or saved transcript, and does not switch Assistant's route. Unsupported adapters and unavailable execution policies still require a supported route.

If the account credential expires after generation has already produced work, Builder stops that turn but keeps the generated draft and visible progress available for review. It does not automatically replay the provider turn; retrying is an explicit new action.

After either of the first two, whatever it wrote last is kept and stays in review, so you can read it, say what to change, and send it again. When you stop a build yourself, what it had written is discarded instead. Nothing about your installed plugins changes either way: only Add to workspace or Update installs anything.

Iterating on a plugin you already made

Open an installed Builder-created plugin and Plugin Builder loads it as its own project workspace. The header keeps Open and History within reach; less common actions — Edit current version, Reset app state, enable or disable, and delete — live in an overflow menu.

To change a plugin, describe the change in chat. Plugin Builder works the same way it did the first time: it builds a version, checks it, tries it out, and fixes what it finds before showing you the result. The installed plugin keeps running exactly as it was until you choose Update. For a stateful app, whatever you do while testing the preview doesn't touch the installed app's real saved data — applying the edit keeps that data intact. If the result isn't quite right, send another chat message and Plugin Builder picks up from what you already have.

Plugin Builder keeps your conversations and your approved history on this device. History opens a timeline of approved versions only — a failed check, a failed preview, or a draft you abandoned never becomes something you can roll back to. Rolling back restores an older approved version after you confirm. Editing and rolling back both require the plugin to be enabled; re-enable it first if you've turned it off. If you have unfinished draft work when you reopen a plugin, Plugin Builder offers to resume or discard it — older drafts, made before Wrengle tracked drafts this way, offer a rebuild instead.

Resetting and deleting do different things. Reset app state clears only the app's own saved data — the plugin, its history, and its conversations stay put. Delete removes all of it: the plugin's files, its approved history, its rollback points, its linked conversations, and its saved data.

What Plugin Builder sends to your AI provider

Your messages and the app being built go to the route selected under Run with in the Builder composer, round after round, for as long as the build runs. It is the same catalog as Assistant—Wrengle AI, direct OpenAI or Anthropic, and approved external ACP coding agents—but the selection and conversation belong to Builder. Changing it does not reroute Assistant. A direct OpenAI or Anthropic route uses your provider key. Wrengle AI needs no provider key: the prompt and reply transit Wrengle and OpenAI and consume prepaid credits on the signed-in account. An external agent can send context to its own provider. The model receives only Wrengle's Builder capabilities over MCP; its native file, shell, and web tools are disabled. Those Builder capabilities can still perform bounded execute, fetch, or network work during generation according to the selected permission intent. Earlier Builder turns go too—that is what lets a follow-up build on what came before instead of starting over.

The shape of your workspace — folder names, note counts, the tags and note fields you use — can go as well. No note content is included in that.

Note content follows two explicit paths. Notes chosen from the composer's search are exact Resource grants for that turn only. Broader list, search, and read access begins only after you approve the Builder's permission card, and is limited to that Builder conversation and vault. Until then, Plugin Builder designs from workspace shape, exact attachments, images, and what you tell it. That host-owned card is available under Ask me. Auto approve and Full access require a grant you previously made explicitly in that same conversation and vault; otherwise broad note operations are refused.

The four permission intents are Builder-owned. Ask me pauses at protected actions. Auto approve can approve eligible reversible actions. Plan only removes mutation capabilities. Full access can approve eligible Builder MCP commands and network actions without asking. Writes remain limited to Builder scratch, and vault and Wrengle app-data reads remain denied. Validation, preview, and the human Add to workspace or Update step remain enforced under every intent. These controls do not change the Assistant's permission setting or restore the agent's native tools.

External Builder processes start only when Wrengle can enforce its Builder work profile. The current process sandbox is available on macOS; external Builder routes fail closed on unsupported platforms. The scratch root is kept separate from the vault Resource root. On macOS, a short-lived, host-owned npm preparation process uses scratch HOME and may write Builder scratch and the selected Wrengle-owned adapter cache; package lifecycle scripts are disabled, and that process exits before the adapter starts. The long-lived adapter can write only scratch. Both phases deny reads of the vault and Wrengle app-data roots. The current sandbox still permits ambient reads elsewhere that the launched command could normally perform, so the exact reviewed adapter and its dependencies remain trusted code; do not treat the profile as a general secrecy boundary for other user files. ACP filesystem callbacks are disabled. The model receives only Builder capability tools over authenticated HTTP MCP or a bounded stdio fallback, never the agent's native file, shell, or web tools. Wrengle opens no session unless the exact pinned adapter version and executable match its reviewed policy and the host can apply that adapter's reviewed MCP-only options. The upstream adapter does not report a runtime policy acknowledgement, so unknown or changed versions fail closed. An approved external agent may still request network or fetch work through the bounded Builder capabilities while generating. The installed plugin remains offline regardless.

Checks and the test run happen locally on this device. Diagnostics about a build stay local too, unless you choose to share them yourself.

Review before you add or update

Before you choose Add to workspace or Update, Plugin Builder shows you exactly what the plugin can reach:

For offline feature apps, the state keys are exactly what your draft declared, and the generated code is checked against that list before Add to workspace or Update unlocks. If you regenerate or refine the draft, you review and approve it again before it installs — a previous approval never carries over.

That approval is bound to the exact generated manifest and view bytes. Any change creates a new code identity that needs approval again; the installed app's local state remains available after you approve an update.

What generated code cannot do

Generated plugin runtimes and views must not use external network calls, unmanaged secrets, raw filesystem access, shell commands, keychain access, direct access to the desktop process outside the window.wrengle bridge, parent-DOM access, plugin-defined OAuth, or connector install flows. None of that is available to anything Plugin Builder produces.

Apply rejects generated network and peer-connection code. Installed views also receive the same mandatory host-owned offline policy as manual views, including blocked direct networking and host-installed peer-network guards.

Wrengle serves view documents from memory through a private address on this device. This local preview and installed-view transport does not grant plugins external network access; generated code still uses only the allowed host bridge.

The test run also requires that a custom view actually render something you can see, before it's eligible to apply. A view with only hidden markup, only placeholder text, canvas- or blob-drawn visuals, an empty or broken SVG, or a raster image Wrengle can't decode stays in review with attention guidance instead of installing. Static visuals should use inline or embedded SVG with real shapes, or a plain non-interlaced PNG; other embedded raster images are treated cautiously. SVG and image markup generated by JavaScript is also blocked by this check, even when used for a small icon. Put SVG icons in the static HTML, or use text checkmarks and CSS for controls created dynamically.

Managing installed plugins

Broader developer controls for plugins in general — not just Builder-made ones — live under Settings → Plugins → Developer. Permission and key controls for any local plugin live under Settings → Plugins → Management; a Builder app's saved data resets from Reset app state in Plugin Builder itself, not from Settings. Settings → Plugins → My plugins is a second place to enable, disable, or delete a Builder-created plugin without opening Plugin Builder itself.

Current limits

• A rendered plugin view document is limited to 6 MiB, including its embedded images, other assets, and Wrengle's host scripts. This is separate from the limits on reference images attached to a Builder prompt.
• Everything Plugin Builder creates stays local to this device in v1. There is no marketplace, publishing, ratings, payments, moderation, remote discovery, connector distribution, remote install, external plugin network access, plugin-defined OAuth, or connector install flow.
• Plugin Builder builds local custom views and stateful feature apps. It does not build networked plugins, marketplace listings, or generated WASM actions in this release.
• External ACP coding-agent routes require the macOS Builder process sandbox in this release. On unsupported platforms they fail before the prompt is admitted, retaining the complete draft so you can choose another route.
• Shared-auth external Builder generation currently requires Wrengle's exact reviewed Claude Code 0.70.0 adapter policy and an app-scoped Claude account sign-in shared with Assistant. An existing sign-in is reused. Gemini CLI and Codex fail closed with a typed unsupported result and stay Assistant-only until their pinned adapters can provide the same isolated credential and MCP-only policy. A missing or mismatched policy fails before prompt dispatch and never falls back to an ambient API key or ordinary CLI login.
• Prompts whose generated or installed plugin would require external network access, credentials, secrets, or an unsupported platform are refused before a build starts. Build-time network work requested by an approved external agent is a separate, permission-controlled boundary. When it can, Plugin Builder suggests a version of your prompt that fits what it can build today.