End-to-end encrypted coding agent tasks: what the server can and cannot read

Updated 2026-09-02

Your source repository is never uploaded to Denly; the runner clones, edits, builds and tests it where it already sits. The coordination text around it, meaning task descriptions, plans, agent conversations and attachments, can be encrypted in the browser or on the runner under a passphrase Denly never receives.

Denly is a control plane for coding agents (Claude Code, Codex, Cursor, Grok Build, Antigravity) that run on your own machines and your own subscription: you describe a task, the agent plans it, you approve, it builds locally and opens a pull request. What follows is exactly which of that data Denly's servers can read.

The two boundaries

Data	Encryption off	Workspace E2E on
Repository contents	Never uploaded either way. Cloned, edited, built and tested on your runner.
Task title and description	Stored readable, so the service can deliver it	Ciphertext
Plans and agent conversations	Stored readable	Ciphertext
Attachments	Stored readable	Ciphertext
Recurring schedule title and body, and project documents	Stored readable	Not covered yet – see the gap below
Stage, timing, cost figures, PR links, repository slugs	Readable either way. The service routes and bills on these.

How the key works

The browser and the runner each derive one content key from a workspace passphrase and a per-organization salt with PBKDF2-HMAC-SHA256 at 600,000 iterations, then AES-256-GCM each field into an identical JSON envelope: {"v":1,"iv":"<12-byte nonce>","ct":"<ciphertext and tag>"}. The passphrase never leaves the machine. Only the salt, which is not secret, and the envelope are uploaded.

Because both halves produce byte-compatible envelopes, a task written in the browser is readable by the runner and a plan written by the runner is readable in the browser, with the server holding neither key nor plaintext at any point.

Turn it on

Enable end-to-end encryption for the workspace and set the passphrase. It is entered in the browser and stays there.
Give each runner the same passphrase in its environment.
Restart the runners so they pick it up, and create one task to confirm it round-trips.

Runner environment

DENLY_E2E_PASSPHRASE=your-workspace-passphrase

Two writes are not covered yet, as of 2026-09-02.A recurring schedule's title and body, and a project document saved while the workspace key is locked, can still reach the server as plaintext. Both are open repairs on our side. Until they land, treat those two fields the way you would treat an unencrypted one; everything else on this page holds today.

Passphrase loss is permanent.Denly holds no key and no recovery copy, so nobody at Denly can restore encrypted history for you. Store the passphrase where you store your other workspace secrets.

What it does not cover

Two parties stay outside the boundary, because the work needs them:

Your Git host receives the code the runner pushes, under your agreement with them.
Your AI provider receives the context its own CLI sends, under your agreement with them.

Encryption also does not change what the runner uploads when you ask it to diagnose itself: that is a redacted, curated summary of the local log, never the raw file and never repository contents.

Taking your data out

Settings → Account → Your data downloads everything Denly holds about your account as JSON. Separately, Record agent output on the Defaults screen decides how much of a run is kept at all: Full records messages and the tools it ran, Text keeps the messages and drops the tool results, and Off records nothing beyond the task's own events. It can be set per project.