coollabsio/coolify · error · Exception

You do not have permission to create tokens with write permi

Error message

You do not have permission to create tokens with write permissions.

What it means

Same fresh policy re-evaluation in addNewToken(), this time for write abilities: the submitted permissions intersect ['write', 'write:sensitive'] but the user fails the useWritePermissions gate, so token creation aborts. Write abilities let a token mutate resources, so they are restricted to roles the policy trusts (admins/owners), independent of what the rendered UI suggested.

Source

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

            }
        }
        sort($this->permissions);
    }

    public function addNewToken()
    {
        try {
            $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.

View on GitHub (pinned to 70b9acc424)

Solutions

  1. Request a token without write/write:sensitive abilities
  2. Ask a team admin/owner to create the write-capable token and share it securely if appropriate
  3. Reload the page so the checkboxes match your current standing, then resubmit
  4. Verify the acting user's team role and the PersonalAccessTokenPolicy::useWritePermissions conditions

Example fix

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

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

Strategy: validation

Validate before calling

use App\Models\PersonalAccessToken;

$wantsWrite = array_intersect(['write', 'write:sensitive'], $permissions) !== [];
if ($wantsWrite && ! auth()->user()->can('useWritePermissions', PersonalAccessToken::class)) {
    // strip or reject write abilities before calling addNewToken
}

Try / catch

Catch \Exception inside the token-creation action and dispatch('error', ...); order the checks root -> write -> deploy -> read:sensitive so the first failure names the offending ability.

Prevention

When it happens

Trigger: A MEMBER-role user ticking 'write' or 'write:sensitive'; a demoted admin reusing a still-open tokens tab; a crafted Livewire update adding a write ability to the permissions array.

Common situations: Role downgrades after page load; inviting collaborators as members who then try to mint write tokens; expecting cloud-team semantics to differ from self-hosted root-team semantics.

Related errors


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