AI coding agents are changing how teams build software, and Retool apps are no exception. More and more teams want to hand their app's underlying code to an agent and let it make changes directly, rather than clicking through the Retool editor every time. The problem is that Retool component placement lives inside a large, machine-generated JSON file - not something a human reviewer can meaningfully read through, let alone approve with confidence. And if your organization relies on source control to protect production apps, changes made from a branch outside Retool can't normally be reviewed at all.
Here's a workflow that solves both problems: it lets you or an AI agent edit an app's code directly, while still giving you a clean, reviewable pull request and a safe preview before anything reaches production.
Starting from a blank app can be a good idea.
You don't have to start from scratch to use this workflow — you can protect, edit, and preview an existing app just as well. But if you're building something new with an agent, starting from a blank app can still be a good idea: it keeps the agent's changes isolated from anything already live, so nothing gets touched until you're ready to merge it in. Protecting the app publishes it to your GitHub repository (kind of like a drive folder) via a pull request, which means every change from here on has to go through a PR rather than landing silently in production. Merge that first PR, and the app now exists in your repo as a readable, versioned file
This step matters even if you're confident in your agent: it's what stands between an AI-generated change and a broken experience for your users. Review the diff, merge it, and only then start iterating.
Work on a branch, then push your changes
With the app protected, you can create a new branch to work from. Edit the app directly in code - through your own coding agent, another code engine, or even by hand - the same way you'd edit any other file under source control. Push your changes, and Retool will open a pull request against your repo, just like the initial setup did.
Add a small, harmless "safe-keeping" commit
Before you can preview your branch inside Retool, the branch needs to be published, since Retool won't let you reset onto a branch until the preview has been pushed to the remote repository. This is by design: Retool avoids automatically pushing newly created branches to prevent cluttering the repository with empty ones, so this extra step is necessary to bypass that protection. A simple way to handle this is to add a trivial extra commit once your real changes are pushed: removing a stray space or adding a full stop somewhere in the text is enough. Give it an obvious name (something like "spawn" makes its purpose clear) so nobody mistakes it for a real change. If this branch were ever merged by accident, the worst that happens is a stray punctuation mark - not a broken feature.
Reset your branch to preview the changes
Once the branch is published, you can reset onto it from the Retool editor by pointing it at your remote branch name. This pulls in your remote changes and replaces the app's current content entirely, so it's worth double-checking you don't have unsaved local edits you care about - resetting will erase them.
If the branch isn't valid, Retool will flag it with a notification, which is your cue to go check what's wrong before trying again. Assuming everything checks out, the reset completes, and you'll see your changes reflected in the editor: updated styling, new options, whatever your agent (or you) changed in the code.
Preview safely, then merge
From here, switch to preview mode to interact with a fully functional version of the app running your new branch - all without touching the main branch that's actually serving your users. Once you're happy with what you see, you can merge the pull request and ship the change with confidence, knowing it's already been reviewed and tested rather than pushed straight to production.
Why this matters
The real value here isn't just "you can edit Retool apps in code" - you could arguably do that before. It's that this workflow makes AI-assisted editing reviewable. An agent can make changes directly to an app's code without ever opening the Retool editor, and you still get a proper pull request, a safe preview branch, and a main branch that's protected the entire time. That combination - agent speed with human-reviewable safety rails - is what makes it practical to actually trust an AI coding agent with a production Retool app.
