Editorial introduction
Meaningful risk from Full access defaults and remote authority. Recognizes scoped authentication; no authentication bypass established.
Reading scope: Permission/auth/remote documentation, RPC authorization and installation instructions.
Download the complete original English text · SHA-256 af2398540b30916d5b83cdcb7bd904e2564a80695c4343598399506bf8050798
Complete original response
Yes—there is meaningful security risk, particularly when running agents or enabling remote access. At commit d13fc84, I would treat T3 Code as a privileged remote-control tool for your development machine.
My targeted source and documentation review found these concerns:
| Risk | What it means |
|---|---|
| Full access is the initial default | Agents can run commands and edit files without approval prompts. A mistaken instruction or prompt injection could therefore cause damage using your account’s permissions. Permission modes |
| Projects are not filesystem sandboxes | A connection with filesystem:read can read files outside the selected project if your operating-system account can read them. That potentially includes private source, .env files, and credential files. Authentication boundary |
| Normal pairing grants powerful access | The documented default includes shell and agent operation. The project explicitly explains that these capabilities can be used to mint sessions with every scope. A compromised paired device or session could therefore mean compromise of your user account. Pairing authority |
| Cloud access adds another trusted party | T3 Connect uses proof-bound credentials, but its own documentation states that a compromised relay signing key remains dangerous. This is a trust assumption, not a vulnerability I demonstrated. T3 Connect design |
| The install command is not pinned to your linked commit | The README’s curl … | sh executes a live installer, and npx t3@latest fetches the current package. Neither guarantees you install the code reviewed here. Installation instructions |
There are also positive controls: the code defines RPC permissions and scoped sessions, and the documented authentication design includes one-time pairing and proof-bound tokens. I did not establish an authentication bypass or find evidence of deliberate malicious behavior in the material inspected. That does not establish that the tool is safe. Authorization implementation
My recommendation for trying it:
- Use a disposable VM or a separate OS account without personal credentials.
- Set new threads to Supervised, and check existing threads separately.
- Start with local access; enable remote connections only when needed.
- Pin an exact release and inspect the downloaded installer before executing it.
This was a targeted static review, not a complete audit of dependencies, release binaries, or runtime behavior. I would avoid first testing it on a machine holding production credentials.
Fixed but not yet released (awaiting review): Nothing.