Permissions
Who can see and change what: workspace and team roles, private work, connected tool access, and API access.
Workspace roles
Workspace owners manage Billing, workspace settings, integrations, members, apps, and taxonomy. Workspace admins help manage workspace settings and access, and can start the first upgrade when the workspace is not yet on a paid account. Workspace members participate in work.
Team roles
Team admins, members, observers, and coordinators have different scopes inside a team; Roles lists what each can do.
Todo visibility controls whether a native todo is private to one person or shared with the team. Shared work can appear in planning, standups, recaps, and team views when the viewer has workspace access.
Team data is scoped to team membership. People outside a team should not see that team's recaps, standups, insights, or team journal just because they are in the same workspace. Workspace owners have broader administrative visibility, so keep that role limited.
Synced issues and pull requests remain governed by the source system. A private todo can hide native work, but it cannot make a Jira issue, GitHub pull request, or Linear issue private in the source tool.
Connected tool access
Connected tools such as GitHub, GitLab, Bitbucket, Slack, Jira, Linear, and Google Calendar keep their own permissions. Each user's integration data is scoped to the accounts, organizations, projects, repositories, channels, and calendars they authorized. Organization-level installs such as Slack or the GitHub App still rely on the provider's own admin approval and access controls.
API and app access
API Keys have workspace-level read and write access and can be revoked. OAuth Apps act with user-granted access. Webhooks send selected workspace events to registered HTTPS endpoints.
Agent execution boundary
Session creation queues work. Execution starts after an agent claims the session, and local agents are owner-only so execution stays on the machine of the user who started the agent.