Four areas carry the risk. Supply chain: MIT source on a fast nightly cadence in the 0.0.x range, commonly launched via npx, with a large dependency surface and no published certifications. Remote access: T3 Connect and the local pairing flow issue credentials the project itself tells you to treat like passwords, and a valid pairing credential creates a session until it expires or is revoked. Credentials: each agent CLI holds its own login on disk, which means T3 Code never proxies a token and also means nothing central can revoke one. Governance: no policy, no audit export, no allowlist, no admin. None of this makes T3 Code unsafe. It makes it a tool whose controls are entirely at the endpoint, which is a finding a reviewer needs to see written down.
- The confidentiality story is genuinely strong. T3 Code proxies no tokens and sees no prompts.
- The project’s own docs say: "Treat pairing URLs and pairing tokens like passwords." Believe them.
- Anyone with a valid pairing credential can create a session until it expires or is revoked. That is remote code execution on a developer machine.
- Five agents means five separate credential stores on disk, each revocable only on that machine.
- Nothing central exists: no policy, no audit export, no allowlist, no admin, no revocation.
- Version 0.0.x on nightly builds is a supply-chain posture, not just a version string. Pin it.
- The correct finding is usually "endpoint-controlled tool", not "unsafe tool".
The short answer for a reviewer
T3 Code is an open-source control plane that runs coding agent CLIs on a machine you already control. It does not host your code, does not proxy your provider tokens, and does not see your prompts. In terms of data flow to a third party, it is close to the best case in its category: the vendor is not in the path at all.
The exposures are elsewhere. They are, in order of how often they matter: a remote-access feature that grants full control of a developer machine to whoever holds a pairing credential, an agent that executes commands with the permissions of the user who launched it, a five-way credential sprawl with no central revocation, and a fast-moving dependency surface with no certifications behind it. None of these is unusual for a local developer tool. All of them need to be written down rather than assumed.
| Area | Posture | Residual risk owner |
|---|---|---|
| Data to vendor | Strong. No token proxying, no prompt visibility | None |
| Source transparency | Strong. MIT, public repository, auditable | You, if you audit it |
| Remote access | Needs controls. Pairing credentials grant machine control | The developer holding the laptop |
| Agent execution | Standard for the category. Runs as the launching user | The developer |
| Credential lifecycle | Weak. Five stores, no central revocation | The developer |
| Central policy and audit | Absent. No org concept exists | Nobody |
| Vendor assurance | Absent. No DPA, SLA, or certifications | Nobody |
Supply chain: MIT, npx, and a version that starts with 0.0
T3 Code is published by T3 Tools Inc at github.com/pingdotgg/t3code under the MIT license, with roughly 19,700 stars at the time of writing. It ships desktop builds for macOS, Windows, and Linux, mobile apps for iOS and Android, a web app, and a CLI. Installation is commonly npx t3@latest, with brew install --cask t3-code and winget install T3Tools.T3Code as packaged alternatives.
Three supply-chain observations for the review.
- The version number is a posture, not a technicality. The project ships nightly builds and its README asks users to expect bugs. A team tracking latest across many machines is accepting whatever landed on main that day. Pin a version and upgrade deliberately.
npxinstallation resolves and executes at run time. That is normal in the JavaScript ecosystem and it is still a live code-execution path from a registry. Prefer the packaged installers, or a pinned version with a lockfile, over an unpinned@latestin a shared setup script.- MIT and public means auditable, not audited. The right sentence for a risk register is that the source is available for review, not that it has been reviewed. If your policy requires a third-party assessment, note that the project publishes no certifications, which is expected for an un-monetized project.
Remote access: T3 Connect, pairing tokens, and what a credential grants
This is the area a reviewer should spend the most time on, and it is the area least covered in enthusiastic write-ups. T3 Code offers several ways to drive a machine remotely: a direct connection over your local network, a private mesh such as a tailnet, desktop-managed SSH launch, and T3 Connect, a free minimal open-source tunnel layer set up with a single npx t3 connect. Each user can connect up to three devices, and the service is currently provided at no charge.
The convenience is real and so is the exposure. The pairing model is token-based: the server issues a one-time owner pairing token, the remote device exchanges it, and the server creates an authenticated session for that device. After that, access is session-based and the original token is not needed again unless you pair something new.
The project documents the consequences plainly, and these sentences belong in your review verbatim rather than paraphrased.
- "Treat pairing URLs and pairing tokens like passwords."
- "Anyone with a valid pairing credential can create a session until that credential expires or is revoked."
- "Hosted pairing links keep the credential in the URL hash so it is not sent to the hosted app server, but it can still be exposed through browser history, screenshots, logs, or copy/paste."
Unpack what a session grants. It is control of a coding agent on a developer workstation, which means the ability to read the repository, read anything else that user can read, run commands, and reach whatever the machine can reach. A leaked pairing link is not a data-exposure incident, it is remote code execution as that developer. The documentation is not hiding this, and it is a materially different risk from a leaked read-only dashboard link.
Prefer the private network over the public tunnel
The documentation recommends a trusted private network that meshes your devices together, such as a tailnet, for stability, network-layer security, and reduced exposure. If you already run one, use it. This is the single largest risk reduction available and it requires no compromise on functionality.
Treat pairing links as short-lived secrets in policy
Never paste one into a chat channel, a ticket, or a document. Never screenshot a screen showing one. This needs to be a written rule, because the failure mode is friendly and casual rather than adversarial.
Know the revocation command before you need it
Use t3 auth to revoke old links and sessions. Confirm the exact subcommands on your installed version and put them in the offboarding checklist rather than looking them up during an incident.
Audit paired devices on a schedule
Three devices per user is a small number, which makes a periodic review cheap. Somebody should be looking at what is paired, quarterly at minimum, and immediately whenever a device is lost or a person leaves.
Decide whether remote access is on at all
For teams working on sensitive repositories, the correct answer may be that remote control is disabled and the feature is simply not used. That is a legitimate configuration and it removes this entire section from your risk register.
Credentials: five agents, five stores, no central revocation
T3 Code drives Claude Code, Codex, Cursor, Grok Build, and OpenCode, and it authenticates none of them. Each is installed and logged in through its own CLI: claude auth login, codex login, agent login, grok login, and opencode auth login. The credential each of those mints lives on that machine, in that tool’s own location, under that tool’s own lifetime.
This design has a genuine security virtue that is worth stating before the criticism. Because T3 Code never handles a token, there is no central store to breach, no vendor that can read your prompts, and no intermediary accumulating credentials for many users. Compared with a hosted control plane that proxies everything, the blast radius of a T3 Code compromise is one machine.
The cost is that revocation is also one machine at a time. There is no console that can invalidate an engineer’s Claude Code session, no org key that can be rotated to cut everyone off at once, and no inventory of who is authenticated to what. Long-lived tokens are the specific hazard: a credential minted for automation can outlive a seat by a very long time, which our seat management guide treats as the standard offboarding gap across this whole category.
| Question | Answer under T3 Code |
|---|---|
| Who holds the provider credential? | The agent CLI, on the developer’s machine |
| Can T3 Code read it? | It does not proxy tokens. Each CLI talks to its own provider |
| Can an admin list who is authenticated? | No. There is no admin and no inventory |
| Can an admin revoke centrally? | No. Revocation is per tool, per machine, or in the provider console |
| What survives a laptop being returned? | Every credential on it, until the disk is wiped or each is revoked |
| Is there a shared secret to rotate? | No, and that is a genuine advantage |
What is not there: policy, audit, and the org boundary
The last section of a review is usually the shortest and the most consequential. T3 Code has no organization concept, so it has none of the controls that hang off one.
- No model policy. Any model any connected CLI exposes is available. A decision that a model is not approved for your codebase has no enforcement point.
- No network allow or block lists. Whatever the agent can reach, it can reach. Restricting the sites an agent fetches is not a setting.
- No org-scoped audit. Thread history is local. There is no export, no retention policy, and no way for a reviewer who was not on the machine to reconstruct what an agent did.
- No roles. Every user is their own administrator. There is no separation between someone who sets limits and someone who works within them.
- No vendor assurance. No DPA, no SLA, no certifications, no security contact with a commitment attached. Issues and Discord are the support surface.
The general agent-security controls that do apply are the endpoint ones, and they apply regardless of which control plane you run. Prompt injection through content the agent reads, over-broad credentials reachable through tools, and unreviewed output entering production are the three that actually cause incidents. Our coding agent security guide covers the four containment layers that hold, and every one of them is configured at the endpoint, which is exactly where T3 Code leaves them.
The review checklist
Take this into the meeting. It is ordered by how often each item turns out to be the one that matters.
- Is remote access enabled at all? If yes, is it over a private mesh or the public tunnel?
- Is there a written rule that pairing links are never pasted or screenshotted?
- Is
t3 authrevocation in the offboarding checklist, with the exact commands? - Are paired devices reviewed on a schedule, and immediately on departure or device loss?
- Is the T3 Code version pinned, and does somebody read the diff before upgrades?
- Is installation through a packaged installer or a pinned version rather than unpinned
npx @latest? - Is there an inventory of which engineers are authenticated to which agent providers?
- Does offboarding revoke each agent CLI login individually and rotate any API keys held?
- Is there a documented model policy, and is it recorded as unenforced?
- Is there any org-scoped record of agent activity, and if not, is that accepted in writing?
- Does any customer contract require a DPA, an SLA, or a named vendor for developer tooling?
- Are the endpoint containment layers configured: permission rules, sandbox, scoped credentials, containers for unattended runs?
Items one through six are cheap and remove most of the realistic risk. Items seven through eleven are the ones that no amount of endpoint configuration fixes, because they need something that models an organization.
Where a managed vendor differs, and where it does not
If your review stalls on items seven through eleven, the remedy is a control plane with an organization in it. Being precise about what that changes matters, because a managed vendor also introduces exposures that T3 Code does not have.
What it adds: a central inventory of who has access, one-step offboarding, a policy enforcement point, an org-scoped activity record, and a counterparty who can sign something. In Continuum’s case specifically, offboarding cuts provider access, revokes devices and tokens, and destroys the content key together; model policy resolves at organization, team, and member scope with a lower scope able to narrow but never reopen; every session records the tool calls made and the URLs fetched; and the storage posture is forced row-level security on every tenant table, AES-256-GCM for transcripts at rest, XChaCha20 for the owned-device relay, and hashing for every key held.
What it costs. On the hosted path, prompts pass through the vendor gateway on purpose, because pre-flight policy and budget checks are the only thing that makes a cap enforceable. Direct and bring-your-own-key sessions run machine to provider and send usage only, which preserves the T3 Code confidentiality property at the price of a weaker control. Transcript sync, when enabled, stores pages encrypted at rest under a per-member key, which the organizations page describes as encrypted rather than zero knowledge. That is a distinction worth carrying into your own review.
And the honest limits, since a security page that only lists strengths is not a security page. Continuum has no SAML, OIDC, or SCIM today; sign-in and invitations run on WorkOS AuthKit with Google and Apple login. Org-wide network allow and block lists are scoped as an Enterprise engagement rather than a self-serve setting, so restricting which sites an agent reaches is a conversation, not a toggle. Hosted cap decisions are admin-only. And there are no published third-party certifications, which for some reviews is decisive.
If your conclusion is that T3 Code is fine with endpoint controls, that is a legitimate and common outcome. The teams page covers the thresholds where it stops being fine, and the enterprise alternative page covers what to do when a procurement row eliminates it outright.
Questions people ask
Is T3 Code safe to use?
For most developer environments, yes, with endpoint controls in place. It proxies no tokens and sees no prompts, which is a strong confidentiality position. The exposures are remote-access pairing credentials, agent execution with the launching user’s permissions, credential sprawl across five CLIs, and the absence of any central policy or audit.
Is T3 Connect secure?
It is a tunnel with a token-based pairing model, and the project documents its own caveats: pairing URLs and tokens should be treated like passwords, and anyone holding a valid pairing credential can create a session until it expires or is revoked. The documentation recommends a trusted private mesh such as a tailnet where you have one.
What does a leaked T3 Code pairing link actually let someone do?
Create a session that controls a coding agent on that machine, which means reading the repository and anything else that user can read, running commands, and reaching whatever the machine can reach. Treat it as remote code execution as that developer, not as a read-only link.
Can I revoke T3 Code remote access?
Yes. Use t3 auth to revoke old pairing links and sessions. Confirm the exact subcommands on your installed version and put them in your offboarding checklist rather than looking them up mid-incident.
Where does T3 Code store my API keys?
It does not. Each agent CLI holds its own credential in its own location on the machine, minted by its own login command. T3 Code never proxies a provider token, which is why it also cannot report what a run cost.
Does T3 Code have SOC 2 or ISO certification?
No certifications are published, which is expected for a free, un-monetized open-source project with no commercial relationship to certify. If your policy requires a certification for developer tooling, T3 Code cannot satisfy it and no configuration changes that.
Can we restrict which models or sites the agent can reach in T3 Code?
Not through T3 Code. There is no model policy and no network allow or block list. Restriction has to come from the endpoint: agent permission rules, an OS-enforced sandbox, scoped credentials, and containers for unattended runs.
Is self-hosting T3 Code more secure?
It changes the exposure rather than removing it. npx t3 serve runs the backend headless on infrastructure you control, which removes reliance on a hosted pairing app. The pairing credential model, the per-machine credential stores, and the absence of central policy and audit are unchanged.
Sources
Every figure above was read from these pages on August 2026. Vendors reprice without notice; if you find a stale number, tell us.