10 things you didn't know you could do in Retool

If it’s been a while since you last opened Retool, you probably remember dragging a table onto a canvas, nudging it around a twelve-column grid, and wiring it up with a {{ }} expression (or six). It was a solid system, and teams shipped a lot of internal tools faster than they would have coding them by hand.

But there was a catch. Your app lived in a format only Retool understood. LLMs couldn’t work in it fluently, engineers couldn’t bring their own tools, and apps built anywhere else couldn’t run on Retool.

So we changed the foundation. In Retool’s new app builder, apps are React on the frontend and TypeScript on the backend. You build them by prompting an agent, either in Retool or from the coding tools you already use.

No matter where it was built, every app still runs on the permissions, environments, and resource controls your admins already set up, so your security team can easily sign off.

To recap what’s changed, here are ten things you probably didn’t know you can do in Retool right now.

Before you start: An organization admin needs to enable the new app builder. In Settings > AI, toggle on Updated App Builder. See the configuration guide for model setup and permissions.

1. Prompt an app into existence, then edit one component at a time

The new builder starts with a conversation instead of an empty canvas. In the Chat tab, describe the data to use, what should appear on the page, and what users should be able to do, and the agent builds a working app against your real data. You can @-tag a specific resource or let the agent inspect your schemas and suggest one.

You can also attach a screenshot, PDF spec, or brand guidelines, or Figma files for context, pick the AI model for each thread, and switch to Plan mode to review the agent’s plan before it builds. When you only want to change one thing, Selection mode scopes your prompt to a single component, and the rest of your app stays exactly where you left it.

How to try it

1.
From the apps landing page, click Create > App.
2.
(Optional) Click the gear icon in the prompt box to choose a model. Your admin sets the default.
3.
Enter a prompt, attaching files if helpful. Something like:Make me a deploy dashboard. List the last 50 deploys from the @Deployments Postgres table—commit SHA, author, env, status, duration. Add a 'Rollback' button per row that POSTs to /deployments/:id/rollback, but only show it to users in the sre group.
4.
To edit one component, press Mod + E to toggle Selection mode, click the component on the preview canvas, and describe the change.

Read our guide to prompting in Retool (below) to learn more.

2. Read every line of code behind your app, and change what you need

Retool apps used to be made up of configured components defined in Retool’s proprietary language. Now, apps are source code: React 19 with shadcn/ui, Tailwind CSS, TanStack Table, and Recharts on the frontend, and TypeScript functions on the backend that run serverlessly on Retool’s infrastructure.

There’s no black box. You can read and review everything the agent wrote, and even modify it yourself when you need to. The Data tab makes the backend just as legible—every operation against your data is a function you can open, test, and view as a diagram of its control flow.

How to try it

1.
In the app builder’s left panel, open the Code tab to browse every file in your app.
2.
Open a file to read or edit it. A small set of files the agent depends on are view-only.
3.
To add your own code, create a Frontend component (.tsx) or Backend function (.ts) from the Code tab.
4.
Open the Data tab and select a function to run it with sample parameters in the Function playground.

In Change History, your edits appear under your name and the agent’s are prefixed with (Agent).

For file management, keyboard shortcuts, and details on which files are view-only, see the guide to manually editing app code.

3. Build from Cursor, Claude Code, or the tools you already use

Developers don’t have to leave their editor to build in Retool. Two tools connect your environment to your Retool instance:

The Retool CLI (public beta): Your local coding agent, such as Claude Code or Codex, writes app code on your machine with full context of your codebase. The CLI checks that it’s valid Retool code, and because code is written locally, CLI commands don’t consume Retool AI credits.
The Retool MCP server: Your local agent passes prompts to Retool’s app-building agent. It works with clients like Claude Code, Cursor, Codex, and Kiro, and it’s best for exploring resources and apps, managing users, and importing React apps.

Install both, and your agent can choose the right one for each task. Either way, the habits you already have become your path to production: publishing from the CLI still enforces permissions and requires function approvals.

How to try it (CLI)

You’ll need Edit permissions, a terminal or agent environment with bash access, Node.js 22, git, and pnpm.

1.
Install the CLI: pnpm i -g @tryretool/cli
2.
Authenticate: retool auth login --host <example.retool.com>
3.
Install the skill that teaches your agent how to shape a Retool app: retool skill install
4.
In an empty directory outside any git repository, run retool init for a new app (or retool clone for an existing one), then pnpm install.
5.
Run retool start to validate code as you or your agent write it.
6.
Run retool push --wait for a preview build, then retool publish to ship.

How to try it (MCP)

Every client connects to the same endpoint, https://<your-retool-instance>/mcp, over HTTP with OAuth 2.0, and you choose which permission scopes to grant when you authenticate. Beyond that, setup varies by client, so follow the MCP setup guide for step-by-step instructions for Claude Code, Cursor, Codex, ChatGPT, and Kiro.

For a broader walkthrough, including what each scope unlocks, see how to use MCP in Retool.

4. Import a React app you built somewhere else

Prototypes built in Lovable, Replit, or Claude Code often lack data access controls and a deployment path IT has approved. Instead of rebuilding them, you can now import them into Retool.

Retool imports apps with React, HTML, or JavaScript frontends and Node.js or Supabase backends. The agent migrates your frontend and maps each external data source to a Retool resource (an existing one, a new one, or mock data you can swap later). The code that called those sources becomes Retool functions, and the app inherits Retool’s permissions and governance. Results won’t be identical to the original, since dependencies can differ, but apps on a similar stack carry over closely.

How to try it

1.
Export your app as a .zip file (50 MB or smaller).
2.
From the apps landing page, click Create > App.
3.
In the Chat tab, click Import React code and select your .zip.
4.
In Connect Resources, connect each data source to an existing resource, create a new one, or use mock data.
5.
Click Confirm selections to let the agent finish building.

Already building in Retool? The Chat tab also offers Convert classic app, which rebuilds your existing Retool apps in the new builder and leaves the original untouched. Conversion is free on Team, Business, and Enterprise plans.

To see how the agent maps each type of data source, or how to export a project from Lovable, Replit, or Claude, read the doc on importing external React apps.

5. Design layouts without a grid, and get mobile for free

Old Retool apps sit on a fixed 12-column grid, which makes standard layouts quick and everything else a workaround. The new builder has no prescribed layout or grid, so it can be whatever you and the agent decide.

Apps are also mobile-responsive by default, so one build adapts to desktop and phone screens without a separate mobile layout to maintain. Every app has a light and dark mode, and you can restyle any app by prompting. On Business and Enterprise plans, admins can also define organization-level themes for consistency across apps.

How to try it

1.
Describe the layout you want in the Chat tab as specifically as you can.
2.
Use Selection mode to refine one section at a time.
3.
(Business and Enterprise) Open the theming selector at the top of the preview canvas to apply an organization theme and preview light and dark mode.
4.
For small tweaks, edit the code directly in the Code tab.

Admins can learn how to create organization themes and set a default in the doc for customizing app themes.

6. Build the same app in parallel with your teammates

Work in the new builder is organized into threads and branches. A thread is a single conversation with the agent. A branch is a set of changes with its own preview and change history, and it’s the unit of work you publish.

The app builder is collaborative. Each builder works on their own branch, then publishes their changes so the rest of the team sees the updates. One teammate can overhaul a page while another changes the app’s resources, with nobody waiting their turn.

When you publish, Retool checks for conflicts with the published version and other builders’ changes. If a teammate published first, click Integrate changes and the agent resolves the conflict.

How to try it

1.
In the navbar, open Change History.
2.
Click + to create a new branch from the latest published version.
3.
Build in one or more threads. Switch branches under Changes in progress.
4.
Share a preview link from the Working Branch tab with teammates who have Edit access.

The docs on threads and branches explain how the two fit together, including how branches map to git in protected apps.

7. Bring in public npm packages

In the past, if you wanted to go beyond Retool’s components, that meant building a custom component library. In the new builder, if what you need already exists in the open-source ecosystem, you can ask the agent to install it.

Retool puts guardrails around this. Only public packages are supported, each version must be at least five days old (compromised packages are often discovered quickly), and packages need a permissive open-source license such as MIT, Apache-2.0, or BSD. The agent always asks for approval before installing anything, and admins can turn off third-party packages in Settings > Advanced settings. You’re still responsible for vetting each package before you approve it.

How to try it

1.
In the Chat tab, ask for the package by name, for example: "Use the lightweight-charts npm package for my charts."
2.
Review the install request and approve it if you trust the package. Make sure it supports React 19.
3.
Prompt the agent any time to update or remove a dependency.

Before you approve a package, review Retool’s best practices for third-party packages.

8. Put a human checkpoint in front of data changes

AI that writes code against real data needs a checkpoint, and the new builder puts one where it matters most. Before the agent runs a function that writes, updates, or deletes data, it asks for your approval in the Chat tab. Read-only functions run automatically, and the agent won’t run destructive statements like DROP TABLE at all. By default, when you test the app in preview, Retool asks you to approve data-changing function runs too.

Publishing adds a second checkpoint: the Publish checklist requires any function that creates, updates, or deletes data to be approved, and confirms there are no conflicts before the app goes live. And if a release turns out to be wrong, Publish history keeps every published version, so you can restore an earlier one and republish it.

How to try it

1.
Click Publish in the top-right corner of the app builder.
2.
In the Publish checklist, click Review functions to approve any outstanding functions.
3.
Set the App URL and choose a folder. Everyone with Use access to that folder can use the app.
4.
(Optional) Expand Tags & publishing to tag the release as Major, Minor, or Patch.
5.
Click Publish.

To roll back, open a thread in the Chat tab, then go to Change History > Publish history, click Restore on the version you want, and publish again. If you tag releases, you can instead pin an earlier tag from the footer of the Publish history tab.

The publishing guide also covers release tagging and publishing on custom domains.

9. Get governance by default, with no new security model to learn

Normally, the people controlling who has access to what are reluctant to have grant more people access. But in Retool, more builders doesn’t mean more work.

Apps in the new builder use the same permissions model as before: admins assign Use, Edit, or Own access to apps and resources through permission groups, and resource environments keep development and production data separate. Everything IT already approved applies automatically.

Published apps are only accessible to authenticated users, and on Business and Enterprise plans, admins can use role-based access control to decide who can use the AI app builder at all. LLMs are only involved while someone is building. Published apps never route runtime data through an LLM.

How to try it (Business and Enterprise admins)

1.
Navigate to Settings > Roles and select the automatically created App Builder Role.
2.
On the Assignment tab, remove the default All Users group and click Add group assignment to grant access to specific groups or users.
3.
Click Save changes.

The configuration guide walks through the full admin setup, and the app security page details exactly what the agent sends to LLM providers while you build.

10. Let AI build with your data, without giving it more access than you have

Prompting should never become a way to skirt around security rules. In Retool, your permissions are the agent’s permissions—nothing more and nothing less. The agent can’t read or write any resource data you aren’t already authorized to access, and functions the agent runs execute server-side under your authenticated session, with the same permission checks as any other request from you.

For finer control, Enterprise organizations can use access policies, currently in public beta for PostgreSQL resources, to define which tables, columns, and rows each group can read or write. Policies live at the resource level, so they apply to every query against it, whether it comes from an app, the query library, raw SQL, or an agent. Policy changes and blocked queries are written to audit logs.

How to try access policies

First, make sure the resource’s Disable converting queries to prepared statements option is off. On self-hosted instances, also turn on Enforce data security using access policies in Settings > Beta.

1.
Navigate to Resources and open a PostgreSQL resource you have Own access to.
2.
On the Access Enforcement tab, toggle on Data access enforcement and click Save changes. This closes the resource to everyone, including admins, until a policy grants access.
3.
Click Create policy and enter a name. Add groups under Apply to, select environments, and choose Full access or Granular access to set table, column, and row rules. Click Save draft.
4.
Click Activate on the policy, then Save changes.

Check which workflows use the resource first: workflow runs that can’t be attributed to a user, such as scheduled or webhook-triggered runs, are blocked on enforced resources.

The guide to configuring access policies covers row filters and exceptions in more detail, and the app security page explains how Retool enforces the agent’s access while you build.

Retool isn’t the Retool you remember

Retool was originally built on the bet that the fastest way to build internal software was to move away from code and toward drag-and-drop. AI changed that math. Now you can prompt an app, read every line of it, build it from your own editor, or bring it in from somewhere else, and however it’s built, it runs under the same controls your admins already trust.

Ready to see it for yourself? Sign up for Retool and follow the apps quickstart guide to build and publish your first app.