gitstalk
Install the plugin Sign up
Docs: Collaborators and visibility

Collaborators and visibility live

The 20-second answer: four roles (read, write, maintain, owner), three visibilities (private, public, internal) and one rule that decides access the same way over git, MCP and the web.

Roles

  1. readclone, fetch, view
  2. writealso push beans
  3. maintainalso deploy tokens, Actions secrets, protected paths
  4. ownereverything, settings and deletion
Role May
read Clone, fetch, view.
write Also push beans.
maintain Also manage deploy tokens, run workflows and manage Actions secrets, and change protected paths and approval rules with their own token or SSH key. It is the role that may answer decision cards (see the note below).
owner Everything: visibility, collaborators, archive, transfer and delete. Not invitable. For an organization's repository, the organization's owners and admins are owners.

Invite people

Only the owner opens Settings, Collaborators. Type a Gitstalk handle, pick a role (read, write or maintain; the default is write) and invite.

Invite by handleThey accept or decline on their Home.
dana  |  write
@ada maintain since 3 weeks ago Change role
@lee read since 2 days ago Remove
@dana invited as write until Oct 28, 2026, 10:00 AM Cancel invitation
Change a role or remove someone in the same list. A role takes effect on the person's next request.

Invitations wait 14 days and appear on the invitee's Home, where they accept or decline. An access log under the list records every invitation, answer, role change, removal and leave, plus visibility changes, transfers and changes to Actions secrets and variables, and every approval of a held bean.

Email invitations are planned: Gitstalk sends no mail yet, so invite by handle. Teams are planned too.

Visibility

Private live

Only the owner and people they invite. Anyone else gets a 404, as if it did not exist, on every transport.

Public live

Anyone reads and clones, signed in or not. Pushing still needs a role.

Internal live

For an organization's repositories only. Every member of the organization, any role, reads and clones it. Anyone else gets a 404.

The owner changes it in Settings, Visibility. A personal repository cannot be internal, and an internal repository moved to a person becomes private.

One rule, every transport

Access is decided in one place for HTTPS git, SSH git, MCP and the web. Tokens, keys and agent sessions get their person's role, capped by their scopes: a token with only read access cannot push, whatever its person may do. Three things are a person's alone and no git token, SSH key or deploy token may do them: answering decision cards, managing deploy tokens, and changing settings.

A deploy token is bound to one repository. It never decides or administers, and it does not depend on collaborators.

The People tab

Open it from any repository you have a role on. It lists who has access and every credential that cloned or pushed.

Who has accessYou are maintain: also answer decision cards and manage deploy tokens.
@coop owner · @ada maintain · @lee read
laptop git for @ada, SSH key last read 2 min ago, last push 1 h ago 3 pushes
Claude Code for @coop, agent over MCP last read 9 min ago, last push 9 min ago 12 pushes
ci-deploy for @coop, deploy token last read 3 days ago 0 pushes
Leave acme/apiFor collaborators; the owner cannot leave.
Leave
Every agent session, token and key acts for a person. The table shows who, through what, last read, last push and how many pushes.

On a public repository, someone with no role sees only that it is public and who owns it.

Organizations

Organization roles, the base permission and how they combine with a collaborator role are on Organizations. The short version: a collaborator role on one repository adds to what an organization gives, and the stronger one counts.

Sources