Retool CLI push blocked by cliFileAuthorization on unchanged /context/ files created by Retool Agent

Hi,

I'm using Retool CLI 0.4.36 with a React app converted from a Classic app using the new Retool Agent / App Builder.

The Agent created a retool-agent/ branch.

I cloned that exact branch with the CLI, made changes only to the application frontend/backend files, and:

retool check

passes completely.

However, retool push is rejected server-side with:

[cliFileAuthorization] CLI changes are not allowed for
/context/linked-classic-app/.positions/.clients.positions.json.
Restore this Retool-managed path before pushing.

We investigated this extensively and confirmed that the flagged file has not been modified locally.

Git topology:

origin/main = 4f38881 "Newly created app"

The /context/ directory does not exist on main.

Retool Agent later created:

/context/linked-classic-app/

in commit:

f60fb14 "Write classic app conversion context"

on the retool-agent/ branch.

The flagged file has exactly the same Git blob everywhere:

ce02b4e6e0ebf3c54e0fe1583c156fbb70206141

The blob is identical in:

  • the working tree
  • HEAD
  • the remote retool-agent branch
  • the parent of my local application commit
  • the original Retool Agent commit f60fb14

My local application commit modifies zero files under /context/.

We also ruled out local file normalization:

  • core.autocrlf is unset
  • core.eol is unset
  • no applicable .gitattributes rules
  • LF in both index and working tree
  • no BOM
  • no CRLF
  • no git diff on the flagged file

However:

git diff origin/main HEAD -- context/linked-classic-app/.positions/.clients.positions.json

reports the file as a pure addition (36 insertions, 0 deletions), because /context/ was created by Retool Agent on the agent branch and does not exist on main.

This seems consistent with cliFileAuthorization evaluating the Retool-managed path against a server-side baseline where /context/ does not exist, rather than against the current retool-agent branch head.

I cannot confirm which baseline the server-side gate actually uses, but this behavior fits all the observations above.

Since /context/ is Retool-managed and the CLI policy does not allow it to be modified or deleted, I don't see a safe client-side workaround.

What is the supported CLI workflow for pushing frontend/backend changes from an Agent-created branch that contains Retool-managed /context/ files?

I have not modified or deleted anything under /context/ and have not attempted to work around the authorization gate.

I already reported the issue using retool feedback:

Feedback ID: a6389b6a-6f0a-49e9-965b-25d2fa7561b8

CLI version: 0.4.36
Launcher version: 0.1.4

Thanks!

Summary

Using the Retool CLI (0.4.36) with the new app builder, a React app was converted from a Classic app by the Retool Agent, which created a retool-agent/ branch containing Retool-managed /context/ files. After cloning that branch and changing only frontend/backend files, retool check passes but retool push is rejected server-side with a [cliFileAuthorization] error claiming an unchanged /context/ file was modified β€” likely because the gate evaluates the Retool-managed path against a baseline (main) where /context/ never existed, treating it as a net-new addition.

AI Response

The supported CLI workflow is to clone the branch, run pnpm install, validate with retool check, then retool push and retool publish. A key documented step for Agent-created branches is to run retool pull first: if a branch was updated on the server (for example, by an agent thread that pushed the conversion context), you must pull to bring local state back in sync with the true branch head before pushing. Doing so realigns your local baseline with the server's retool-agent branch head β€” which contains /context/ β€” rather than a baseline where /context/ is absent, which is consistent with the addition-versus-baseline behavior observed. Retool-managed paths under /context/ should be left untouched (not modified or deleted) throughout. No existing community report was found corroborating this specific cliFileAuthorization behavior as a confirmed bug.

Sources

:bookmark: Retool CLI | Retool Docs
Documents the supported CLI build/push flow and specifically instructs running retool pull to re-sync local state when an agent thread has pushed to the branch before you push again.
:bookmark: Retool CLI Public Beta
The Retool CLI Public Beta announcement confirms the CLI is the supported tool for building, managing, and publishing Retool-native React apps and links to the current workflow docs.

The Community Team is testing out a new automation. Let us know if it's helpful (or not) by leaving a :heart:, :+1:, or :-1:. Or by marking this post as the "Solution"! Let us know if you have any feedback here. :rocket:

Thanks for the suggestion. I tested the recommended retool pull workflow, but unfortunately it does not resolve the issue.

Before running the pull, the working tree was clean and my local branch was exactly one commit ahead of the remote retool-agent/... branch.

I ran:

retool pull

Result:

βœ“ pull: nothing to fetch: retool-agent/7f02ef36-752f-4f4a-9fa4-0dcd2de06c8f is already in this checkout's history, and you have 1 local commit(s) to push.
Pulling resource types…
βœ“ pulled 42 resource type file(s) for env "production".

I then checked the repository again with git status. The working tree was still clean and the branch was still one commit ahead.

I then ran:

retool push

All local checks passed:

βœ“ hooks: passed
βœ“ validate: passed
βœ“ typecheck: passed
βœ“ build: passed
βœ“ check: all required local phases passed

But the server-side gate still rejected the push with exactly the same error:

βœ— push rejected by the gate:
[cliFileAuthorization] CLI changes are not allowed for /context/linked-classic-app/.positions/.clients.positions.json. Restore this Retool-managed path before pushing.

So in this case, running retool pull first does not fix the issue.

The reported /context/ file was not modified by my local commit. It was created by the Retool Agent during the Classic β†’ React conversion and was already present on the retool-agent/... branch before my changes.

This still seems consistent with cliFileAuthorization evaluating the Retool-managed /context/ file against a baseline where that file did not exist, rather than against the current retool-agent/... branch head.

Please let me know if there is any additional diagnostic command or information I can provide to help confirm this.

Hello!

First off, thanks for trying out the CLI and sorry that you ran into this! You found an edge case that we are patching ASAP.

In the meantime, could you try this set of instructions:

  1. In the Retool editor, open the app and the conversion thread (the retool-agent/... branch you cloned).
  2. Publish that thread as is. It should still match the state from before your CLI work. If the editor asks you to bring in changes from main, accept them. Note that publishing makes the converted app live for your users.
  3. In your CLI checkout, run retool pull. It will report that your branch has diverged and print a git rebase <sha> command. Run that command.
  4. Try retool push again

Let us know if that worked for you!

Justin

thank you, perfect