Retool CLI 0.4.65 returns 401 on /cli/resource-types/metadata after successful OAuth login

💬 App Building
,
1
  1. My goal:
  2. Issue:
  3. Steps I've taken to troubleshoot:
  4. Additional info: (Cloud or Self-hosted, Screenshots)
2

Summary

Using the new Retool CLI (v0.4.65) on a Retool Cloud instance, a request to /cli/resource-types/metadata returns a 401 immediately after an apparently successful browser OAuth login.

AI Response

This endpoint is the resource-types pull that the new Retool CLI performs during commands like init, start, and pull, and it requires a live session whose token carries the react_apps:write scope on the exact instance being targeted. A 401 right after a browser login most commonly means the command is pointed at a different host than the one that was authenticated, the cached session has expired, or the token is missing the required scope. Run retool auth status to confirm the token's scopes and expiry and retool whoami to verify the signed-in instance, then set the correct target with retool auth use <url> or pass --host explicitly (or sign in again with retool auth login --host <your-instance>). Because 0.4.65 is an early beta, also run retool update so the CLI core matches the version the instance recommends, and re-run with --debug to confirm which host the 401 originates from. Retool and its auth dependencies are currently fully operational, so this is not a known platform incident.

Sources

:bookmark: Retool CLI reference | Retool Docs
The Retool CLI reference documents that commands need an authenticated session with the react_apps:write scope and shows the auth status, whoami, auth use, and --host controls needed to resolve a 401 on the resource-types pull.
:bookmark: Retool CLI Public Beta
The Retool CLI Public Beta announcement confirms this is the new (non-classic) CLI, where it's available, and the install/update flow for keeping the beta CLI version in sync with the instance.

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:

3

Hi Retool team,

Adding the full diagnostic details here, as the body of my original post was accidentally submitted with only the template.

Environment:

OAuth device authorization completes successfully and the CLI recognizes the authenticated session.

The instance manifest (GET /api/cli/manifest) returns 200 OK and recommends core 0.4.65, which is the version currently installed.

However, running:

retool status --json

fails with:

types status failed: 401 Unauthorized – Authentication failure. Missing access token

We isolated the failure to the resource-types metadata endpoint. Using the same authenticated session:

  • GET /cli/context → 200
  • GET /cli/preview → 200
  • GET /commits → 200
  • GET /refStatus → 200
  • GET /cli/resource-types/metadata → 401

CLI debug output indicates that the Authorization header is present on all of these requests, including the request that returns 401.

Troubleshooting already performed:

  • Renewed OAuth authentication using device authorization; the issue persisted.
  • Confirmed the same user, HOME, credentials path, and Retool host are being used.
  • Confirmed the installed CLI core matches the version recommended by the instance.
  • Reproduced the 401 with a direct Node fetch, without a redirect.
  • Other CLI endpoints continue to return 200 using the same session.
  • Inspected the installed CLI core read-only and confirmed that retool status calls /cli/resource-types/metadata. The fallback to /cli/resource-types appears to occur only on a 404 response, not on 401.

This appears to be isolated to /cli/resource-types/metadata, although we haven't determined whether the cause is route-specific OAuth handling or server-side middleware.

Could someone from the Retool team help verify the authentication handling for this endpoint or advise on the next diagnostic step?

I can provide additional sanitized debug information if needed. No tokens, cookies, or credentials are included here.

Thanks!

4

Quick update after an additional controlled test:

I noticed that retool auth status --json initially reported the OAuth session as expired: true and refreshable: true.

I then ran retool apps --host https://estudosialucas.retool.com --json, which successfully triggered the CLI's automatic token refresh and listed the HELP Cloud Dashboard app.

Immediately afterwards, retool auth status --json reported:

  • expired: false

  • refreshable: true

  • scope: cli:*

  • a new future expiresAt

I then immediately reran retool status --json.

It still failed with exit code 1 and the same error:

types status failed: 401 Unauthorized – Authentication failure. Missing access token

The failing endpoint remains /cli/resource-types/metadata.

So the issue is reproducible even with a freshly refreshed, non-expired OAuth session, while retool apps succeeds using that session.

5

Update — Oct 3

We have now reproduced the issue again after renewing the OAuth session. Authentication completes successfully and the session reports expired=false, but retool status --json still fails specifically on /cli/resource-types/metadata with 401 Unauthorized — Authentication failure. Missing access token.

We have also reported the issue today through two official Retool channels:

  • retool feedback from the CLI — Feedback ID: a963a8f3-e350-439c-94a3-db197cfcde64

  • “Submit feedback” from the new App Builder

Retool CLI: 0.4.65
Launcher: 0.1.10
Retool web: 4.69.0
Environment: WSL

This is currently blocking our intended Retool CLI + Codex local development workflow. Could someone from the Retool team confirm whether the 401 on this specific endpoint is a known CLI/App Builder authentication issue, or whether our app requires an additional authorization/configuration step?

We are happy to provide any additional diagnostics needed.