#Read-only mode

#Turning it on

Request the narrower scope at login:

labdash auth login --read-only

Or use a personal access token created with read_api instead of api. labdash records the scopes it was granted at login and behaves accordingly.

#What changes

Three things happen, and nothing else:

1. A read-only badge appears in the context bar, so the mode is always visible.
2. Mutating keys leave the ? overlay, and grey out in the footer. Pressing one answers with the reason rather than sending a request that is certain to fail.
3. Everything else behaves exactly as it does with a full token.

Cannot merge — this token is read-only, so labdash cannot change anything.

The keys stay visible because the keymap is fixed and nothing is rebindable. A key that vanished would be a key nobody could ask about.

The left column is most of the product. A read-only labdash still reports what is waiting, what is blocked and why, and which assertion failed.

#A 403 from a mutation

Scopes are recorded at login, so labdash usually knows before it tries. If a mutation does come back 403, because the token was narrowed after login or the instance disagrees, the message names the cause:

gitlab.example.com refused that — this token is read-only. Create one with the
api scope at https://gitlab.example.com/-/user_settings/personal_access_tokens?scopes=api,
then press Ctrl+A to sign in again

The message is never a raw API error and never a silent no-op. The URL is that instance's own, subfolder and all, not gitlab.com's.

A 403 that is about your permissions rather than your token — merging into a protected branch, say — is left alone. A new token would not help, so labdash does not suggest one.

#Reasons to use it

• Least privilege. A dashboard that only reads cannot merge anything through a mis-keyed m.
• Shared credentials. A group access token scoped to read_api gives a whole team a dashboard without giving a whole team write access.
• Policy. Some organisations do not grant api to a desktop tool.