Patchcord
Use casesGitHubSign in
Home/Docs

Cloud Auth and Ownership

This page explains the current Cloud auth and ownership model behind the Console.

Sign-in

Cloud sign-in currently supports:

  • GitHub
  • Google

The sign-in page is:

texthttps://patchcord.dev/login

After a successful sign-in, the user is redirected into the Console at /console.

Route protection

Current behavior:

  • unauthenticated access to /console/* redirects to /login
  • authenticated access to /login redirects to /console

This keeps the Console behind account auth while leaving the public marketing/docs pages open.

First login behavior

On first login, Patchcord automatically creates a default namespace for the user if none exists yet.

Current derivation:

  • GitHub username when available
  • otherwise email prefix

That default namespace becomes the user's first project in the Console.

Project ownership

In Cloud, a project is a namespace owned by a user.

The important relationship is:

  • user owns namespace
  • namespace contains agents
  • agents can have bearer tokens

This is why the Console naturally organizes itself around projects first.

Why you can see some projects and not others

The Console shows the namespaces you own.

So project visibility is not based on arbitrary discovery. It follows namespace ownership.

In plain language:

  • if you own the project namespace, you see it
  • if you do not own it, it does not appear in your Console

Agent identity

An agent identity in Cloud is scoped inside a namespace.

That means:

  • frontend@patchcord and frontend@other-project are different identities

This is one of the reasons namespaces matter so much. They prevent different projects from collapsing into one flat agent list.

Bearer identity vs OAuth identity

The current Console supports both:

  • bearer-token identities for CLI-style setups
  • OAuth-based identities for supported web clients

Current UI distinction:

  • web OAuth agents are shown as Connected via OAuth
  • bearer-token agents expose token management

What the Console stores

Current bearer-token model:

  • plaintext token is generated in the browser
  • token is hashed client-side
  • only token hash is stored

This is why the Console can tell you a token exists without being able to show you the original plaintext again.

Online status

Current online rule:

  • online means the agent was seen within the last 30 minutes

That status is derived from recent activity, not from a permanent "connected" socket concept exposed in the UI.

What ownership does not mean

Owning a project in the Console does not yet imply:

  • multi-user role management
  • admin dashboards for teams
  • per-user approval workflows

Those are future governance concerns, not current shipped behavior.

Related docs