twinny
install VS CODE
security

Nothing leaves your network unless you send it.

For the security review: every connection twinny can make, what it keeps and where, and what an admin controls. All of it is checkable in the source.

data flow

One path, inside your walls.

The extension talks to one server. The gateway talks to your models.

every connection
fromtowhenwhat goes
VS CodeYour model server or gatewayAlwaysPrompts and the code context you attach. This is the only connection twinny needs.
GatewayModel serversAlwaysThe same requests, to the backends you configured, on your network.
Teammate’s computerGatewayIf someone sharesIt connects out to the gateway with its own key; nothing dials in. Prompts stream through it and are not kept there.
VS CodeA hosted APIOnly if a developer adds onePrompts, with secrets replaced by placeholders first. Team policy can forbid any provider but the gateway.
VS CodeA paired deviceOnly if you pair oneDirect and encrypted between your two machines. The DHT that finds them learns a key and an address, never traffic.
GatewayYour git hostGit or shared-context plugin onReads pull requests and issues, clones the repositories you name for shared context, posts reviews if you allow it.
GatewayYour chat webhooksNotification plugin onEvent lines: a review finished, a backend went down, a sign-in.
GatewayYour identity providerSSO plugin onAn OpenID Connect sign-in.
GatewayYour backup bucketBackup plugin onA nightly archive, encrypted before it leaves the machine if you set a passphrase.
Extension or gatewaytwinny, rjmacarthy.xyzNeverNo telemetry, no update check, no crash reports, no licence check. There is no endpoint.

VS Code updates extensions from the Marketplace on its own; install twinny as a VSIX to bring updates in by hand. twinny itself never checks.

what is kept
Usage
Time, capability, key, model alias, outcome and duration per request. On the gateway’s disk, 30 days.
Content
Not kept. An admin with a licence can switch recording on per feature; developers are told before they connect, and records are deleted after 90 days by default.
Keys
One per developer, shown once, stored as a hash, revoked live. Requests name a model alias and cannot carry a URL, credential or path.
Audit log
Every admin change, hash-chained so an edited or removed line shows. Filter and export it.
Chat history
On the developer’s own machine, in VS Code’s storage and ~/.twinny. Theirs to delete.
what an admin controls
Policy
Team-only providers, locked models, routing rules that keep a workspace on local backends, a team system prompt. Shown to each developer before they connect.
Agent rules
Turn agent mode off, make every command ask or take commands away, make every change wait for review, keep the agent out of paths, switch MCP servers off.
Secret shield
Tokens, keys and passwords in a prompt are replaced with placeholders before it leaves the machine, and put back in the reply.
Read-only admins
An admin key that can see usage, people and the audit log and change nothing. For the auditor.
SSO
Sign-in through your identity provider, restricted to your email domains.
Metrics
Prometheus at /metrics, for the dashboards you already have.

Policy, agent rules, recording and plugins need a licence.

for the reviewer
The code
The extension and the gateway are one MIT repository. The only private piece is the licence issuer, and it only signs seat counts.
The licence check
A token with the organisation, seats, dates and features, signed with Ed25519 and verified by the gateway against a public key it ships with. Offline, once.
A DPA
There is no data to process: twinny receives nothing from your developers or your gateway. The vendor record is the licence: organisation name, seats, expiry and the email it was sent to. See privacy.
Air-gapped
Every part runs with no internet: bring the VSIX and twinny-server in by hand. See air-gapped.
More detail
policy, recording, audit log in the docs, or ask through the contact form.