What leaves your machine, and how to check.

Data flow

Where your source code goes.

  developer machine
  ┌──────────────────────────────────┐
  │  Manifold (Electron)             │
  │    agent CLI in a real PTY       │ ──→  the model provider you
  │    git worktrees on your disk    │      already have a contract with
  │    ~/.manifold/  (SQLite)        │
  └──────────────────────────────────┘
                    │
                    └──→ github.com   git push · pull requests · update check

  optional, self-hosted   Manifold Server (beta)
  ┌──────────────────────────────────┐
  │  your container, your cluster    │ ──→  the same model provider
  │    per-issue sandbox clone       │
  └──────────────────────────────────┘

  no endpoint operated by us appears anywhere above

There is no Manifold-operated service in the path. Prompts and file contents go from the machine running the agent straight to whichever model provider you configured. Nothing is proxied through, stored by, or replayed by us, because there is nothing of ours in between to do it.

What we receive

Nothing. And one honest exception.

• No account, no sign-in, no licence key. There is no identity to create.
• No telemetry, no analytics, no crash reporting, no usage metrics.
• No first-party backend, so no server-side logs of your activity exist.

State at rest

Where everything lives.

All of it under a single directory you control, unencrypted, on your own disk.

~/.manifold/config.json        settings
~/.manifold/projects.json      registered repositories
~/.manifold/memory/*.db        per-project SQLite: prompts, responses,
                               observations, session summaries
~/.manifold/loop-logs/*.jsonl  automated Loop iterations
~/.manifold/worktrees/...      managed git worktrees
~/.manifold/debug.log          local debug log

The storage root is configurable. Session memory is captured locally to give a resumed agent its history back and to make search work. It is never transmitted anywhere by Manifold. Treat ~/.manifold as you would a local git checkout: it contains your source and your prompts, so it inherits whatever disk encryption and backup policy you already apply to developer machines.

Credentials

Yours, used directly.

• Model access uses your own subscription or API key, held by the agent CLI you installed.
• Git and pull-request operations use your own git credentials and GitHub CLI.
• AI-assisted extras are off by default. The shipped setting is provider: 'none', which returns a local fallback and makes no call.
• On the optional server, the repo-controlled verify command runs with git credentials stripped from its environment, so a change to a repo cannot exfiltrate the push token.

Agent isolation

What an agent can reach.

• Each agent works in its own git worktree on its own branch, so it can't silently touch another agent's work.
• Changes land as commits and pull requests. Your CI and branch protection remain the merge gate; Manifold never merges.
• Embedded web previews are restricted to localhost and can't load external sites.
• On the desktop app, the agent is not sandboxed. It is the vendor's own CLI running as your user, with the filesystem reach that CLI has. Manifold neither widens it nor confines it. On a developer's own machine that is the same trust boundary as running the CLI in a terminal.

If that boundary isn't acceptable for your organisation, that is precisely what the server is for.

Plugin trust boundary

Capabilities, enforced by the host.

  process       plugins run in a forked host process, not the
                main process and not the UI
  manifest      each plugin declares the capabilities it needs
  validation    an unrecognised capability rejects the whole
                manifest, so a typo can't widen reach
  privileged    agent:control · agent:spawn · lm
                workspace:manage · transcription:read
                built-in plugins only, whatever a manifest claims
  identity      plugin ids can't contain a path separator
  storage       per-plugin, escape-guarded
  webviews      own URL scheme, nonce CSP
  vscode shim   imported extensions are never granted capabilities

A plugin you write yourself can read the workspace, keep its own state and contribute views. It can't drive an agent, spawn one, or reach the language model. Those three capabilities are refused to anything that isn't built in.

Verify it yourself

Don't take our word for it.

The desktop app is MIT licensed. Clone it and run these. They are the same checks we run before making the claims above.

$ git clone https://github.com/vippsas/manifold && cd manifold

# no telemetry, analytics or crash reporting: expect no matches
$ git grep -riE "posthog|mixpanel|amplitude|@sentry|gtag|plausible|umami" \
      -- src/ package.json

# AI-assisted features are off by default
$ grep -n "provider: 'none'" src/shared/defaults.ts

# every outbound host referenced in the source, in one list
$ git grep -ohE "https://[a-zA-Z0-9.-]+" -- src/ | sort -u

# the app is signed, hardened and notarised
$ grep -nE "hardenedRuntime|notarize|entitlements" package.json

Limits

What we don't claim.

A page that lists only strengths would not be useful to you. Last reviewed against v0.2.108. The current release is v0.2.110.

• No certifications. No SOC 2, no ISO 27001, no third-party penetration test report.
• No SLA and no support contract. There is no vendor to escalate to.
• No managed configuration. Settings are per-user. A platform team can't currently pin defaults, enforce a runtime allowlist, or push a standard plugin set org-wide.
• The desktop app does not sandbox the agent. It runs with your user's reach, as it would in your terminal. The server confines it in a pod. The app does not.
• Packaged builds target macOS. x64 WSL2 with WSLg is supported through a local source build. There is no Windows-native build today. It's an Electron app, so nothing in the stack prevents one. It simply hasn't been packaged.
• Manifold Server is beta and unpublished. Its source isn't public, so it can't be audited the way the app can.