Hello Railway Support,

I am using Railway CLI 5.49.3 with an interactive OAuth login. Read-only access to my target succeeds, but the documented on-demand PostgreSQL volume-backup command is rejected.

Latest failed attempt:

• UTC time: 2026-09-07 18:18:20Z
• Project: respectful-nature
• Environment: production
• Service: Postgres
• Volume: postgres-volume
• Requested backup name: M23-Part8-PreRelease-2026-09-07
• CLI exit code: 1
• Error code: OAUTH_INSUFFICIENT_GRANT
• Error: Failed to create a backup
• CLI hint: If you believe you have access, run railway login again and ensure the integration has access to this project.

Sanitized command template—the actual project identifier is intentionally omitted:

railway.cmd postgres pitr backup create --project "<respectful-nature project ID>" --environment production --service Postgres --name M23-Part8-PreRelease-2026-09-07 --json

Evidence available before the mutation:

• railway whoami succeeds.
• The account was returned as workspace ADMIN by a read-only authorization query.
• The CLI can resolve the exact project, environment, service, and volume.
• railway postgres pitr backup list succeeds for that exact target.
• The duplicate guard found one older backup, zero records with the requested name, and zero newly timed records.
• Railway Account Settings → Apps shows the authorized app Railway CLI with these scopes: workspace:admin, project:admin, ssh_keys, offline_access, openid, email, and profile.
• In that app, respectful-nature is visibly checked under Selected Projects.
• The selected workspace is visibly checked. Its workspace-level Save button appears enabled in the screenshot, so I cannot claim from the screenshot alone that every displayed workspace selection was persisted.

Recovery attempts already completed:

1. An ordinary Railway CLI login did not resolve the denial.
2. A full railway.cmd logout, followed by railway.cmd login and browser consent, also did not resolve it.
3. After each failed create, the backup list still contained only the older backup; no matching backup or acknowledged workflow appeared.
4. No create command was automatically retried.

Railway CLI v5.49.3's public source shows that this command calls the volumeInstanceBackupCreate GraphQL mutation. The same source classifies OAUTH_INSUFFICIENT_GRANT only after the OAuth session remains live but the resource request is still denied.

Could you please explain how the effective OAuth authorization is resolved for volumeInstanceBackupCreate when the Authorized Apps page displays project:admin and the target project is selected? In particular:

1. Is volumeInstanceBackupCreate supported for the Railway CLI interactive OAuth client with a project-scoped project:admin grant?
2. Is there another account, workspace, project, environment, or volume permission that the mutation requires but the UI does not show?
3. If the displayed grant should be sufficient, could this be a stale grant, authorization-resolution, or backend-policy issue?
4. What is the supported least-privilege remedy that does not require sharing credentials or broadening access to unrelated projects?

Unsupported inference, stated separately: the displayed grant and successful reads make an authorization-resolution mismatch plausible, but they do not by themselves prove a Railway backend defect. I am asking Railway to confirm the effective server-side authorization decision.

No nonsecret correlation or request ID was returned or retained. I can provide the sanitized UTC timestamp, CLI version, target names, and error above, but I will not provide access tokens, refresh tokens, cookies, authorization headers, connection strings, or secrets.

Thank you.