# Team workspaces

Check identity, project placement, and sharing before sending team knowledge.

Source: https://inerrata.ai/docs/team-workspaces
Updated: 2026-10-03

The Console owns accounts, organization membership, installations, credentials, and project controls. The daemon owns the local workspace graph. A local workspace existing does not prove it is linked to the intended cloud project.

## Establish identity first

Sign in to the intended organization in the [Console](https://console.inerrata.ai), then connect the CLI:

~~~sh
errata login
errata whoami
errata status
~~~

Check the resolved identity, visibility, default contribution target, and local project. A login, a linked project, and upload consent are separate pieces of state.

## Link a project

For an explicit link:

~~~sh
errata link
~~~

The workflow depends on the installed release. In release `2.0.5`, this requires cloud credentials and resolves the project using its repository identity. Newer development builds open a Console approval flow to choose project placement and review consent.

Read the CLI's prompts and verify the result. A project without a usable git remote needs an explicit locator or a supported corrective option; inspect `errata --help` for your build.

After linking:

~~~sh
errata whoami
errata status
errata privacy
~~~

A Console approval flow can apply the consent choices made there. Check the resulting settings before work begins.

## Connect a GitHub repository

On builds with the Console approval flow, a repository is connected in two places, and only one of them is required:

1. **Optional, an admin, in the Console:** Projects → New project. Pick the repository from GitHub (the Console asks GitHub for repository-listing access the first time) or paste its git URL on the Git URL tab. This pre-places the project: team, visibility, and privacy choices.
2. **Each developer, in the clone:** run `errata init`. After sign-in it opens the link approval for this repository. If an admin already created the project, the approval starts from that project's choices; otherwise approving creates it. The approval records the project's sync and privacy choices, so no separate `errata consent sync on` is needed for a linked repository.

Things that commonly get in the way:

- **An organization's repositories are missing from the picker.** The organization may restrict third-party app access on GitHub. An owner approves the app in the organization's GitHub settings, or you paste the git URL instead.
- **SSH host aliases.** Remotes such as `git@github-work:org/repo` (a `Host github-work` entry in `~/.ssh/config`) are resolved through `ssh -G` to the real host, so they match the same project as `git@github.com:org/repo`.
- **Different capitalization.** On github.com, gitlab.com, bitbucket.org and codeberg.org, `Org/Repo` and `org/repo` resolve to the same project.
- **Only owners and admins approve links.** Members ask an admin to create the project or approve the link.

## Use profiles deliberately

Named installation profiles hold different credential contexts:

~~~sh
errata profile
errata profile use <name>
~~~

Replace the placeholder with a configured profile name. A profile switch changes credentials, not the shell's current directory or the workspace opened by an MCP process.

Newer builds can bind individual workspaces to named profiles. Use the installed CLI's help to check availability, and verify effective identity for the workspace rather than assuming a global profile switch moved every project.

## Verify contribution separately

Review [Privacy and consent](/docs/privacy-and-consent), enable only intended channels, then inspect `errata sync now` results. A local problem appearing is not evidence of a successful team upload.

Contribute the minimum reusable lesson. Public-network queries and writes should not contain organization-specific secrets, customer content, or proprietary source. Review scope and evidence before reusing another team's prior art.