Security and privacy

Coldtea's safest operating mode is boring: know what is local, know what is shared, and do not paste secrets into places meant for teammates or agents.

This page is for rollout decisions, not legal policy.

Local by default does not mean invisible

The core terminal and editor loop runs on your machine. If you start a local agent in Coldtea, the code checkout and shell are local.

Data can still leave the machine when a tool sends it somewhere:

• The CLI agent may send prompt, context, and tool output to its model provider.
• Git, package managers, test tools, and shell commands may contact the network.
• Team features may sync selected task, plan, log, member, integration, QA, or review data.
• Cloud-backed runs or QA flows may use remote infrastructure when your team enables them.

Use the specific agent, provider, and integration settings for the final answer on what leaves the machine.

Shared surfaces

Treat these as shared unless your team has proved otherwise:

• Task titles and descriptions.
• Implementation plans.
• Session logs.
• Comments, annotations, and review notes.
• Matcha QA setup, runs, and test-user configuration, where enabled.
• Integration setup and linked provider metadata.
• Published or shared artifacts your team chooses to expose.

Do not put secrets, private customer data, or machine-only credentials in those places unless your team has explicitly approved that workflow.

Secrets and credentials

Keep secrets in the systems designed to hold them: provider CLIs, credential helpers, environment managers, secret stores, or local config files that are intentionally ignored by Git.

Avoid copying secrets into:

• Agent prompts.
• Task descriptions.
• Plans and logs.
• Screenshots or copied terminal output.
• Shared setup instructions.

If a worktree needs local-only files, copy only what it needs and understand that the files remain available to commands running in that worktree.

Team rollout checklist

Before rolling Coldtea out beyond one developer, decide these things:

1. Which repos are allowed for local agent work.
2. Which agent CLIs and launch presets are approved.
3. Which work can use cloud-backed runs, if any.
4. Which integrations should be connected to the TeaHouse.
5. Which checks are required before review.
6. Who can invite members and revoke pending invites.
7. What should never go into tasks, prompts, plans, or logs.

Write the rules where the team will actually see them, such as repo instructions or team onboarding notes.

Access troubleshooting

When someone sees the wrong task, repo, or issue, check in this order:

1. The active TeaHouse.
2. The selected team or task board.
3. The person's Coldtea role and team membership.
4. The connected provider account or installation.
5. The upstream repo, issue, or workspace permissions.
6. Any feature flags or build-specific settings for that workspace.

Coldtea cannot grant access that the upstream provider refuses. A connected provider cannot give someone local filesystem access on another teammate's machine.

The rule to remember

Local agents run with local user permissions. Shared team surfaces are shared on purpose. Worktrees separate Git edits, not machine access.

Keep those three boundaries clear and the rest of the rollout gets easier.

Next: permissions, GitHub setup, or Linear setup.