← Back to the comparison

Independent review · Full response

T3 Code

T3 Code · Codex · Security code review

2026-10-22d13fc8467 ↗Public-web access only

Exact prompt

Is there a security risk in installing this tool? Read the security-related code in this repository and understand its encryption and data transmission mechanisms before answering. If a mechanism cannot be verified from the accessible code, say so.
Pinned repository link supplied with the question ↗

The text below is the agent’s complete original response, with its original language identified. The introduction is editorial, not part of the original output or an independently verified conclusion. No installation or attack testing was performed.

Editorial introduction

Confirms authentication and DPoP, while distinguishing signatures from content encryption. Flags plain LAN HTTP, tunnel trust and telemetry.

Reading scope: WebSocket/RPC, tunnel configuration, HMAC/DPoP, secret store, telemetry and runtime downloader.

Download the complete original English text · SHA-256 9415833aaa1d5ae8e285c476ecc149f0a2848f63c3eaa7540d1cc3b03afdd656

Complete original response

Yes—there are meaningful security and privacy risks. I would treat T3 Code as a privileged agent and remote-access tool. The reviewed code contains real authentication protections, but it does not justify calling the tool risk-free or its cloud connection end-to-end encrypted.

I inspected security-relevant source files at commit d13fc846700e5bb7d63e1bfaabb1e55733912b21. This was a static, partial source review; I did not install it, test exploits, or verify published binaries against the commit.

The main findings:

  1. A compromised authorized client can have substantial control over your machine.
    The WebSocket server authenticates connections and applies RPC permission scopes, including filesystem, terminal, provider-management, and agent-operation permissions. Those are meaningful safeguards. However, the repository explicitly recognizes that terminal access is a shell as your user, and agent-operation access can launch a full-access agent. Treat a standard paired device as a highly trusted device. RPC enforcement, permission mapping, documented authority boundary

  2. Encryption depends on the connection route.

    Route What I could establish
    Direct LAN HTTP Plain HTTP is supported. It provides no transport confidentiality for credentials or application traffic.
    HTTPS endpoint Protection depends on TLS and whoever terminates it.
    T3 Connect Cloudflare tunnel configuration forwards requests to a loopback HTTP origin; the reviewed RPC path uses JSON without an additional payload-encryption layer.

    I could not verify application-level end-to-end encryption that excludes Cloudflare from the trust boundary. The configuration is consistent with Cloudflare terminating public HTTPS, so you should assume that infrastructure can access application traffic. I could not verify production TLS versions, tunnel cryptographic settings, or logging from this repository. Direct connection options, tunnel origin and ingress configuration

  3. Authentication uses cryptography, but signatures do not encrypt your data.
    Session tokens contain Base64URL-encoded claims authenticated with HMAC-SHA256 and a random 32-byte server signing key. Verification checks expiration and revocation. DPoP adds P-256/ES256 proofs tied to the request and token, with replay detection. These help prevent forgery and credential reuse; they do not conceal prompts, files, or terminal output. Session implementation, HMAC implementation, DPoP verification, replay protection

    T3 Connect also trusts its relay’s signing authority: a valid relay proof can request a short-lived, client-key-bound bootstrap credential with standard client scopes. A compromised relay signing authority remains consequential. Credential minting

  4. The inspected local secret store is not encrypted at rest.
    ServerSecretStore writes raw bytes to .bin files, restricting directories to 0700 and files to 0600. These permissions help against other OS users, but not malicious software running as you or readable backups. The inspected database layer uses ordinary Node SQLite without a database-encryption key. This finding concerns these storage paths; I did not verify every provider’s credential store. Secret storage, SQLite configuration

  5. Telemetry leaves the machine by default.
    Analytics defaults to enabled and sends HTTPS batches to ingest.t3.codes; the source says the ingest service retains a copy and forwards events to PostHog. Payloads include installation identifiers, platform/version information, and event properties. Identity code derives hashed identifiers from Codex, Claude, and connected accounts—so this is potentially correlatable telemetry. I did not establish that every event excludes sensitive content. The server supports T3CODE_TELEMETRY_ENABLED=false. Telemetry defaults and transmission, identity derivation

  6. Installing “latest” does not install the source you asked me to review.
    The README recommends executing a live downloaded installer or npx t3@latest. The runtime downloader checks SHA-256 against a checksum file fetched from the same release location. That detects mismatches, but does not independently protect against a compromised release publisher. I did not verify the live installers, release signatures, dependency supply chain, or binary reproducibility. Installation commands, runtime verification

My recommendation: first evaluate it under a separate OS account or disposable environment, keep remote access disabled, disable telemetry if unwanted, and use supervised agent permissions. Avoid plain HTTP across a network. For sensitive repositories, require a review of the exact release and remote-access deployment before granting access.

Fixed but not yet released (awaiting review): Nothing.

← Back to the comparison