How Clew handles your code

Last updated 2026-05-29.

Clew turns your repository into an architecture diagram. To do that we have to read your code — but we don't have to keep it. This page is the long version of what we promise at the connect step.

The tone here is deliberately sober. The brand is irreverent elsewhere; this is the trust moment. Every claim below mirrors what's actually in the implementation. If anything reads as overclaim, write to [email protected] and we'll tighten it.

What we keep

For every repository you connect, our database stores only the derived diagram — the modules, the edges between them, the per-module changelog "why", and the list of loose ends. We never persist your source code, file contents, or git history beyond what's reflected in the derived view.

What an ingest looks like

1. A GitHub webhook (push to your tracked branch, or a merged PR) tells our orchestration Worker that a re-sync is due.
2. The Worker spawns a fresh, isolated sandbox for the job — a Cloudflare Container running on a Firecracker microVM — and passes in a short-lived installation token scoped only to your repo.
3. Inside the sandbox we git clone --depth 1 your repo, read its structure with a TypeScript AST parser (ts-morph, no npm install), cluster the import/call graph deterministically (Louvain), and call our LLM only to name and narrate what the structure already says — never to author it.
4. We write the diagram + per-module changelog + loose-ends list to our database. Rows are scoped to your account by Postgres row-level security.
5. The sandbox is destroyed. The clone and the installation token die with it.

What we don't do

• We don't execute your code. No npm install, no require() of repo modules, no eval. The parser reads source files like text and reasons about them statically.
• We don't follow symlinks out of the clone. Any symlink whose target resolves outside the clone root is rejected (path-traversal guard).
• We don't accept pathological inputs. The sandbox enforces a per-file size cap, a total-bytes cap (zip-bomb guard), a file-count cap, and CPU + memory + wall-time caps on the job.
• We don't ask for org-wide permissions. The GitHub App grants contents, metadata, and pull_requests as read-only on the specific repos you pick. No push, no admin, no secrets access.
• We don't train any model on your code. Anthropic's commercial DPA excludes training on commercial API content; we are not Anthropic and we do not train any model at all.

What we keep, in one table

Verify, don't trust

Sub-processors

We are honest about who else touches your data. Our Privacy Policy §5 and our DPA §6 list them in full; the short version:

• Supabase (EU eu-central-1) for the database, auth, and realtime.
• Cloudflare for hosting, the worker tier, the queue, and edge caches.
• Anthropic (US, EU SCCs) for the LLM that names + narrates the graph.
• GitHub (US, EU SCCs) for source-code access via the read-only GitHub App.

We will publish at least 30 days' notice on the Privacy Policy before adding a new sub-processor that processes customer data.

What we explicitly haven't promised yet

We don't claim SOC 2 or ISO 27001 today. We'll seek certification when we go after customers who need it; we're not going to claim it before it's true. The same is true of penetration testing reports, bug bounties, and a public security.txt — these are coming, just not yet.

Reporting a security issue

Write to [email protected]. We respond within one business day. We do not yet run a paid bug bounty.

Operator: Backthread OÜ, Estonia (registration number [REGISTRATION NUMBER], registered office [REGISTERED ADDRESS]). Long-form policy detail in the Privacy Policy, the DPA, and the Terms of Service.