Troubleshooting
Fixes for common problems with keys, providers, the daemon, permissions, the sandbox and the desktop app.
When something goes wrong, Nib tries to say what happened, why, and what to do. If a message doesn't make that clear, that is a bug; please tell us.
Two commands help with almost everything:
/statusin the CLI shows the daemon connection, the session, the model and the workspace.nib --verboseprints diagnostics to stderr, including connection attempts and, in headless mode, every permission denial.
Keys and providers
"Couldn't detect a provider for this key"
Nib recognizes many keys by their prefix, but some providers (DeepSeek, Moonshot, Z.ai, MiniMax, Mistral and others) use keys without a distinctive prefix. Enter the provider's base URL along with the key. See the URLs in Providers and gateways.
401 or 403 from the provider
- Check that the key is active in the provider's console and has credit or quota.
- Some providers issue separate keys for separate products. A Z.ai coding plan key, for example, works only on the coding plan endpoint.
- For gateways, check that the key has access to the model you selected.
"Rate limited by … — retrying in 8 s"
The provider is throttling requests. Nib retries with backoff on its own. If it keeps happening, lower the effort, switch to a model with higher limits, or configure a fallbackModel.
The model doesn't call tools, or calls them wrong
- Make sure the model supports tool calling. Nib's catalog marks models that don't, and won't pick them automatically.
- For local models, check the server's context length. Many runtimes default to 4k or 8k tokens, which isn't enough for an agent; set at least 32k.
- Small models do better with Nib's line-anchored edit format. This is chosen automatically for models Nib recognizes as weaker; for an unknown model id it may not be.
Costs look high
- Check
/cost. If cache reads are near zero, the prompt cache isn't being hit. Switching models or providers mid-session starts a cold cache. - Lower the effort for routine work.
- Use a smaller model for subagents that do broad searches.
The daemon
The CLI says it can't reach the daemon
- If no daemon is running, the CLI starts its own. If that fails, run with
--verboseto see why. A running daemon that doesn't respond is skipped, and the CLI starts a new one for the run. - With
--daemon-url(orNIB_DAEMON_URL), the CLI connects only to that daemon: check the URL and the token inNIB_DAEMON_TOKEN. The token must be the one that daemon was started with.
"reconnecting…" in the terminal UI
The connection to the daemon dropped. The CLI reconnects on its own and catches up from the last event it saw. If the daemon was restarted, the session continues once it's back.
Sessions from the desktop app don't show up in the CLI
They use different data directories by default. Point the CLI at the app's daemon with --daemon-url and its token in NIB_DAEMON_TOKEN, or use the same --data-dir.
Permissions
The agent keeps asking for the same thing
Choose Allow for this session or Always allow (in Allow's menu) instead of Allow. Always allow writes a rule to .nib/settings.local.json. You can also switch to acceptEdits mode with Shift+Tab if the prompts are for file edits.
A command is denied in headless mode
Headless runs can't prompt, so anything not pre-approved is denied. The JSON result lists each denial in permission_denials. Add the tool to --allowedTools, for example --allowedTools "Bash(npm test *)".
An allow rule doesn't seem to apply
- Deny and ask rules win over allow rules. Check every settings file, including
~/.nib/settings.jsonand managed settings. - Compound commands need every part allowed.
npm test && npm run lintneeds rules for both. - The workspace may not be trusted yet. Until it is, the project's own allow rules are ignored.
- In auto mode, very broad rules like
Bash(*)are ignored on purpose. - Writes to protected paths (
.git,.nib,.claude, shell startup files, …) need you in every mode but bypass, whatever the rules say.
"plan mode: present a plan with ExitPlanMode first"
The session is in plan mode, so edits and mutating commands are denied. Approve the agent's plan, or switch modes with Shift+Tab.
Sandbox
Commands fail with "Operation not permitted"
The sandbox blocked something. Nib tells the agent which limit was hit: a write outside the workspace, a read of a protected path, or network access. If the command legitimately needs it, add the path to sandbox.filesystem.allowWrite, open a local port with sandbox.network.allowLocalPorts, allow a host with sandbox.network.allowedDomains, or approve an unsandboxed run when the agent asks. Put these in your user settings (~/.nib/settings.json); a project's own settings can't widen its sandbox.
"Sandbox unavailable"
The sandbox is required here but can't be applied: your, your organization's or the project's settings set failIfUnavailable: true, or sandbox-exec is missing on macOS. On Linux, install bubblewrap (sudo apt install bubblewrap or sudo dnf install bubblewrap); some container environments don't allow the namespaces bubblewrap needs. To run commands unsandboxed with permissions as the only layer, set "sandbox": { "failIfUnavailable": false } in your user settings. On Windows, and on Linux without bubblewrap, commands run unsandboxed unless a setting requires the sandbox (see Sandbox).
Instructions and configuration
My CLAUDE.md or NIB.md isn't being followed
- Check that it loaded: it should be in the project root or a parent directory of where you started. Files in subdirectories load only when the agent works there.
- Check
claudeMdExcludesin your settings. - Long instruction files get diluted. Keep the most important rules short and near the top, and move area-specific guidance to path-scoped rules.
A setting is ignored
Nib drops invalid keys with a warning instead of rejecting the file. Run with --verbose to see warnings. Also check precedence: a value in .nib/settings.local.json overrides .nib/settings.json, and .nib/ overrides .claude/ at the same level.
An MCP server's tools don't appear
Project servers need approval before they connect. MCP tools are also deferred: the agent loads them by name when needed. See MCP servers.
Desktop app
"Nib is damaged and can't be opened" (macOS)
The download was probably interrupted or modified. Delete the app and download it again from nib.gg/download.
The window is blank or the app shows "daemon failed"
The daemon didn't start after several attempts. Choose Restart in the error view. If it fails again, check the logs in the app's log folder (on macOS, ~/Library/Logs/gg.nib.desktop/) and include them in a bug report.
Keys aren't saved on Linux
Nib stores keys through the Secret Service API. Make sure a keyring (GNOME Keyring or KWallet) is installed and unlocked.
nib:// links don't open the app
On macOS the scheme is registered when the app is first opened from Applications. Open Nib once, then try the link again.
Getting help
- Write to support.
- Write to support@nib.gg. The Support page lists billing and security contacts and the service status page.
Include the Nib version (nib --version), your operating system, the provider and model, and what you expected to happen. Don't include API keys or private code.