Access and Roles
Two questions decide everything here: which projects can somebody see, and what can they change once they are in. CodeScout answers the first with project membership and the second with three instance roles plus a level on each membership. The rest of this page is what those add up to.
Visibility
Section titled “Visibility”One rule covers everyone except the super admin: you see the projects you are a member of. No exceptions, no “admins see everything” branch. A project you are not on does not appear, and asking for it directly returns 404 rather than 403. You should not be able to learn it exists.
The roles
Section titled “The roles”Super admin
Section titled “Super admin”A super admin can do everything: change instance settings, open every project without being a member of it, promote other people, and reset an admin’s password.
You can have several, and normally should. With exactly one, the day that person leaves is the day your instance can only be administered over SSH. The first account created on a fresh instance becomes a super admin automatically.
The last super admin cannot be removed or demoted. The instance would be unadministrable.
A role about capabilities, not about scope. An admin may create projects and create accounts, though only Member accounts: promoting somebody to admin is a super admin’s job. An admin sees only the projects they are a member of, the same as anyone else, and creating one makes them its maintainer.
An admin cannot see, or learn the existence of, another admin’s projects. They can reset members’ passwords, not other admins’. They cannot change instance settings.
Member
Section titled “Member”The same visibility rule applies, and a member cannot create projects or accounts. This is the role most people should have.
Per-project levels
Section titled “Per-project levels”Every membership carries a level, which decides what that person can do inside that one project:
| Level | What it allows |
|---|---|
| Viewer | Reading logs, exporting them, and watching live sessions |
| Maintainer | All of that, plus project settings, revealing and rotating the project’s secret, and deciding who else is on it |
Deleting a project needs maintainer on it and the admin role. So an admin can delete projects they own, a member-with-maintainer cannot, and a super admin can delete anything.
API tokens carry your access, not more
Section titled “API tokens carry your access, not more”Anyone signed in can create a personal access token under Personal settings, whatever their role, because a token grants nothing new. It reads exactly the projects its owner reads, resolved by the same code that decides what the dashboard shows them, and it can only read. If a member loses access to a project, every token they hold loses it in the same moment.
This is how an AI agent gets at your logs, covered in Reading CodeScout with an AI agent.
Tokens are personal, so nobody sees or revokes anyone else’s, and deleting an account deletes its tokens along with its sessions.
Passwords
Section titled “Passwords”Password reset is an account operation, not a project one. A maintainer cannot reset a viewer’s password, even on their own project. You may reset roles strictly below yours.
Changing your own password lives under Personal settings, alongside your tokens. Saving it signs out every other session you had open.
Resetting generates a random temporary password, shown once to whoever did the reset, to hand over. The old one stops working immediately and every session it had open is invalidated. The account is forced to change it at next sign-in.
No email is ever sent. That is what keeps docker compose up self-contained, with no SMTP to
configure.
Adding people
Section titled “Adding people”Go to Settings → Members and add them with a name and an email. The email is what they sign in with; there are no usernames.
Project access is editable from both directions: from the Members screen, and from a “Who can see this project” panel in Project settings → Access. The project creation wizard has the same step, so access is decided when the project is made rather than remembered later.
A note for small teams
Section titled “A note for small teams”If everybody on your team genuinely should see everything, scoped access is friction, and the tempting shortcut is to make everyone a super admin. That defeats the model, and it also hands everyone the ability to change instance settings and delete projects.
Add each person to every project instead. The Add member sheet lists all of them with a Select all button, so this is one extra click rather than a policy decision you have to keep making.
We deliberately do not offer an instance-wide “admins see all projects” switch. A setting that changes who can see what means the answer to “who could read this?” depends on when you ask, and that is the kind of question a security review needs one answer to.