Glitch personal access token grants full access to all projects: is this a documented error?

Problem description

Glitch’s personal access tokens are created through the user settings page and are designed to allow programmatic access to the platform’s API. However, each token is granted blanket access to every project owned by the user, including all environment variables, domain settings, and project files. There is no mechanism to restrict a token to a single project or to a subset of resources.

In addition, the token does not contain an expiration timestamp. Once issued, it remains valid indefinitely until the user manually revokes it. This lack of an automatic expiration or time‑to‑live field means that a leaked or compromised token could continue to operate with full privileges for an unrestricted period.

These two characteristics—over‑privileged scope and indefinite validity—represent an unresolved design decision in Glitch’s authentication model. The platform has not published a roadmap or committed to implementing scoped or time‑bound tokens, and community requests remain unaddressed.

Specific questions

• Does Glitch have an official plan to introduce scope‑based personal access tokens or to allow users to specify limited permissions?
• Can users request a time‑bounded token through the API or settings interface, and if so, what parameters are required?
• What is Glitch’s current policy for automatic revocation or expiration of personal access tokens, and are there any mechanisms to enforce it?