coollabsio/coolify · error · Exception

You do not have permission to create tokens with read:sensit

Error message

You do not have permission to create tokens with read:sensitive permissions.

What it means

The fourth fresh gate in addNewToken(): 'read:sensitive' is submitted but the user fails useSensitivePermissions, so creation aborts before auth()->user()->createToken() is reached. Sensitive-read abilities expose masked fields (credentials, env vars) and are therefore gated like the other privileged abilities, re-checked server-side on every submit.

Source

Thrown at app/Livewire/Security/ApiTokens.php:131

            $this->authorize('create', PersonalAccessToken::class);

            // Re-evaluate policies fresh against the current authenticated user.
            // Never trust $this->canUse* booleans — they come from the Livewire
            // snapshot which can be replayed from another user's session.
            if (in_array('root', $this->permissions, true) && ! auth()->user()->can('useRootPermissions', PersonalAccessToken::class)) {
                throw new \Exception('You do not have permission to create tokens with root permissions.');
            }

            if (array_intersect(['write', 'write:sensitive'], $this->permissions) && ! auth()->user()->can('useWritePermissions', PersonalAccessToken::class)) {
                throw new \Exception('You do not have permission to create tokens with write permissions.');
            }

            if (in_array('deploy', $this->permissions, true) && ! auth()->user()->can('useDeployPermissions', PersonalAccessToken::class)) {
                throw new \Exception('You do not have permission to create tokens with deploy permissions.');
            }

            if (in_array('read:sensitive', $this->permissions, true) && ! auth()->user()->can('useSensitivePermissions', PersonalAccessToken::class)) {
                throw new \Exception('You do not have permission to create tokens with read:sensitive permissions.');
            }

            $this->validate([
                'description' => 'required|min:3|max:255',
                'expiresInDays' => 'nullable|integer|in:7,30,60,90,365',
            ]);
            $expiresAt = $this->expiresInDays ? now()->addDays($this->expiresInDays) : null;
            $token = auth()->user()->createToken($this->description, array_values($this->permissions), $expiresAt);
            $this->getTokens();
            // Do NOT strip the numeric prefix (e.g. "69|...") — Sanctum uses it to index and look up tokens.
            session()->flash('token', $token->plainTextToken);
        } catch (\Exception $e) {
            return handleError($e, $this);
        }
    }

    public function revoke(int $id)
    {

View on GitHub (pinned to 70b9acc424)

Solutions

Submit the token without read:sensitive
Route the request through a user who holds the sensitive-read ability
Reload the tokens page and resubmit with the abilities actually offered to you
Verify conditions in PersonalAccessTokenPolicy::useSensitivePermissions if access seems wrong

Example fix

// blade: before
<input type="checkbox" value="read:sensitive" wire:model="permissions">

// blade: after
<input type="checkbox" value="read:sensitive" wire:model="permissions"
    @if(!auth()->user()->can('useSensitivePermissions', \App\Models\PersonalAccessToken::class)) disabled @endif>

Defensive patterns

Strategy: validation

Validate before calling

use App\Models\PersonalAccessToken;

if (in_array('read:sensitive', $permissions, true)
    && ! auth()->user()->can('useSensitivePermissions', PersonalAccessToken::class)) {
    // drop read:sensitive from the request
}

Try / catch

Catch \Exception in the creation action, dispatch('error', $e->getMessage()); do not catch-and-continue - a partially-privileged token must not be silently created.

Prevention

Bind the read:sensitive checkbox state to the live ability check
Prefer non-sensitive tokens for automation; request elevation explicitly
After audits/permission changes, refresh the page before creating tokens

When it happens

Trigger: A user without sensitive-read standing ticking 'read:sensitive'; a replayed snapshot from before the ability was revoked; crafted wire updates appending the ability.

Common situations: Automation that needs env values requested by non-privileged members; post-audit permission tightening followed by stale tabs; multi-user teams with mixed roles.

Related errors

AI-assisted analysis of coollabsio/coolify@70b9acc424 (2026-08-17). Data as JSON: /api/errors/c7acf2b325e0d238. Report an issue: GitHub.