What Wanigan protects, and what it does not

The core is the process that owns the database and every terminal. It listens on a Unix socket inside a data folder with mode 0700, so only your user can open the folder, and the socket itself is 0600.

Every caller presents a token. The window holds the owner’s. Each session gets its own when it starts, and the wanigan command in that session can use only the methods marked session in the ACCESS map in src/shared/protocol.ts, only inside its project. The owner, and paired phones allowed to act, can approve a card; an agent session cannot.

The window is treated as untrusted. It reaches the core only through window.wanigan, can call only owner methods, and the core validates everything it sends.

Phone access is off by default. Turned on, it starts a separate HTTP gateway on 127.0.0.1:47832; its optional Tailscale mount serves /wanigan over HTTPS on your private network. The setting persists across core restarts.

• A single-use pairing code grants a phone its own token. Phone methods have an explicit allowlist, and acting needs that phone’s Can act permission.
• A phone can read the list of accounts, but never change accounts, settings, git, keys or pairing.
• Forgetting a phone blocks its token and closes its event streams. After a request’s body arrives, the gateway checks the token and Can act again just before it acts, so a held request cannot keep a permission revoked while it was arriving. Work already started may carry on after revocation.
• A pairing code works once, for ten minutes; after ten wrong codes in a minute, pairing waits. Each phone’s key is kept on the Mac only as a hash.

Account discovery checks file names. Sign-in checks ask each CLI who is signed in, without reading or copying Claude Code’s or Codex’s credential files. A TypeSafe key for Jev is saved readable by your user only and is never sent back to the window.

For Gemini CLI, Wanigan reads your Gemini settings and trusted folders and never writes back to them. Into its own Gemini home it copies your sign-in method, your trusted folders, and only the MCP servers that hold nothing that could be a credential: every environment and header value must be a reference such as $TOKEN, with nothing key-like in a command line, address or other setting. When in doubt a server is left out, and the MCP view says why without showing the value. It never copies Gemini’s credential files or anything that looks like a key, token or password.

Plugin manifests, MCP files and skill folders a plugin names are checked against the installed plugin’s own folder before they are read. Anything that points outside it is left unknown, or left out with a note, while the healthy ones still show. These checks are not an atomic filesystem transaction and do not exclude another program writing at the same moment.

• Only the project’s own local site is opened. A hosted environment is read-only: its own private session, never the helper’s token, its certificate checked as any browser would, and only requests that read. Wanigan asks a hosted site for nothing in the background.
• The page’s DevTools are the page’s own, with none of Wanigan’s privileges.
• A recording never keeps what is typed in a password field, or a request’s body, headers, cookies or query. A snap’s blur replaces the pixels before the picture is kept or sent.
• Voice input turns speech into text on your computer: the audio never leaves it. Only Wanigan’s own window may use the microphone; a site in the live view never can.
• The site helper is written into the site only when you install it, after showing what it writes and runs. It is kept out of git and removed on your click.

More on each: the site helper, Snap and Record, Compare and Local and Live.