Troubleshooting and where data lives

When an app hides its data, you cannot back it up, move it or tell what it knows. Wanigan keeps all of its own in ~/Library/Application Support/Wanigan 2/, and the demo keeps its in ~/Library/Application Support/Wanigan 2 Demo/. Your projects, boards and history live there, not in the app, so replacing the app keeps them.

Not in it: your agents’ conversations and sign-ins, which stay where the agents keep them (History reads them and never writes), and local models, which LM Studio keeps in ~/.lmstudio/models.

Nothing is written into a project to make Wanigan work: hooks, instructions and the wanigan command are handed to each session as it starts. These do write, each only when you click, and each says first what changes:

• Copying a skill to a project, or adding a project’s MCP server, writes there.
• The site helper is written into the site when you install it, with a line in .git/info/exclude so git never sees it, and removed on your click.
• A card’s own branch and git’s record of its worktree are in your repository, as with any git worktree; the worktree’s files are in Wanigan’s data folder.
• What you save yourself: a file in the code editor, words saved into a template with Look in its template…, a template copied into your theme with Create override…, and commits, merges and stashes in Changes.
• Make it real saves into the site’s own database, through its core, as you; not into your files.

A terminal that dies with the window loses an agent’s work. So sessions run in Wanigan’s core, a separate process that keeps the database and every terminal, and keeps going after you quit.

• Quitting with sessions running asks first: “2 sessions keep running. Wanigan won’t notify you while it’s closed.” Quit, Keep open, or tick Don’t ask again.
• It exits by itself ten minutes after the last session ends with no window open, and not while an AI review, a Jev read or a Talk to Wanigan answer is running, or while phone access is on. The demo’s core ends a minute after its window closes.
• A terminal ends with the core it runs in, so stopping or restarting the core ends every session.
• Wanigan’s mark at the top of the rail shows the core’s state on its corner: nothing while it runs, a ring while it connects, a red dot when it is gone.

Building from source compiles the terminal and database modules for Electron. Install the Xcode Command Line Tools (xcode-select --install), make sure you are on Node 22.23.2 (nvm install in the folder reads .nvmrc), then run npm run rebuild.

If Electron behaves like Node and prints “Wanigan cannot start with ELECTRON_RUN_AS_NODE set”, your shell sets that variable; a terminal inside a code editor can. Start it without: env -u ELECTRON_RUN_AS_NODE npm run dev.

The app is signed ad hoc and not notarized, so macOS says it could not verify Wanigan 2. Click Done, then open System Settings › Privacy & Security, scroll to Security and click Open Anyway beside the note about Wanigan 2. The steps, with why, are in Install the app.

A band above every view gives the reason and names the log, with Try again and Show the log in Finder. Nothing works until the core starts, because it keeps the board and runs every session. In a build from source, a terminal or database module built for another Node fails this way: run npm run rebuild.

The live view says why in the page’s place, with what to do; nothing is changed without your click. The usual causes:

Every case, with its exact words, is in When the site is not shown.

A helper set up by another Wanigan (another Mac, a reinstall, a test) answers only to that one. Layers says “This site’s helper answers to another Wanigan”, and Go to says so too; Set up the helper… sets it up again for this one (more).

Codex reports nothing until its first turn begins, so the composer says “Answer any startup questions and send your first message in the Codex terminal.” Do that; the composer works for the turns after. A Codex session without its hooks is answered in its terminal, and says so.

Gemini’s first screen may ask you to sign in or to trust the folder, so its first message goes in its terminal; the composer works from the next one. In a folder it has not been told to trust, it loads no hooks until you answer, and Needs you shows it as not yet started.

The session reads Hit its limit, and Needs you lists it. For Claude Code, Continue on carries the conversation and its card to another account with room, after one confirmation, sending the whole conversation again; or Wait for the reset. A Codex conversation continues only in the account it lives in. Gemini CLI draws its own dialog (keep trying, switch model, or stop), answered in its terminal. A local model has no plan limits at all.

The new version finds the old core still running and asks: “Wanigan’s core is from another build”. Restart ends the live sessions, since a terminal ends with its core. Keep using it leaves them running and talks to the older core, where what changed may not work until it restarts. Update between pieces of work if you can.

The mic says why, beside the box, with what to do and Try again:

The first press offers to download a speech model; nothing listens until one is on this computer (Settings › Voice).

The logs are in Wanigan’s data folder. They contain paths on your Mac, your projects’ among them, so read one before you attach it to an issue, and cut anything you would not post.

For a problem in the window itself, View › Wanigan’s Developer Tools (On a Mac, ⌥⇧⌘I·; on Windows and Linux, Ctrl+Alt+Shift+I) opens the window’s own console.

Still stuck? An issue helps most with your macOS version and what claude --version and codex --version print. A security problem goes privately, never in a public issue.

• How to tell usWhat to include, and where it goes.
• Honest statusWhat is known not to work yet, before you report it.
• Security and privacyWhat Wanigan protects, and how to report a problem privately.

Open an issue on GitHub, or report a security problem from the repository’s Security tab.