Corey Corey
Start with Corey
GuidesHow it worksWhat is insidePricingDocsStart with Corey

Troubleshooting Corey

In progress

Most Corey problems are connection problems, and they split three ways: the connector is added but not signed in, the app needs a full quit rather than a new chat, or something is pointed at a folder that has been moved or renamed. Ask Corey to "check my setup" first - it audits structure, backup and connection, and names the specific fault.

Start here: ask Corey

Before working through this page, ask Corey directly:

shell
Check my setup

Corey audits three things and reports what it finds: whether your folder is properly organised, whether it is safely backed up, and whether everything is actually reachable. It runs read-only and offers to fix what it finds. If Corey itself is unreachable, it cannot answer, and the rest of this page is where to look.

The one that catches people out

Something moved. If your Corey folder has been renamed, moved to another drive, or tidied into a different parent folder, everything pointed at the old location quietly stops working.

This is worth understanding because the symptom is misleading. A local MCP server checks its folders when it starts. If it cannot reach them it stops rather than starting with nothing, so one missing folder removes every tool that server provided, not just the ones for that folder. What you see is a disconnection message that never mentions a path, which sends most people looking in the wrong place.

If you moved your folder, fix each thing that points at it:

  • Cowork - click Work in a folder below the message box and choose the folder’s new location.
  • Your Claude Project - it stores the folder too. Reopen the project and point it at the new location.
  • The CLI - update COREY_HOME in your ~/.zshrc or ~/.bashrc, then open a new terminal.

Claude Desktop

Corey is listed but has no tools. Adding the connector and signing in are two separate steps. Open Settings > Customize > Connectors, find Corey, and click Connect. Sign in when the Corey page appears. Your account is created on first sign-in.

You changed a setting and nothing happened. Claude Desktop reads connector configuration at startup only. Closing the window or starting a new chat is not enough. Quit fully with Cmd+Q (macOS) or right-click the taskbar icon and choose Quit (Windows), then reopen.

Corey is on, but it cannot see your files. Corey and Cowork are separate switches. In the message box, check the connectors and tools icon has Corey switched on, and that Cowork is toggled on with Work in a folder pointed at your Corey folder.

Editing configuration by hand. Do it with the app fully quit. Claude Desktop holds its configuration in memory and rewrites those files when it exits, so an edit made while it is running is discarded without warning.

Claude Code CLI

Check what is connected first:

shell
claude mcp list

Every server you expect should be listed and connecting. If Corey is missing, it was probably added to a single project rather than to you.

Corey only works in one folder. It was added with --scope local. Add it again for every project:

shell
claude mcp add --transport http corey https://mcp.getcorey.ai/mcp --scope user

claude: command not found. Claude Code is not on your PATH. Reopen your terminal after installing, and check your shell file sources the right directory.

Signed in but no tools. Run /mcp inside a session and authenticate there. The browser sign-in is what creates the account; there is no key to paste.

You are being billed for API usage you did not expect. Corey runs on your Claude subscription, so there is no API key to set. But if ANTHROPIC_API_KEY is set anywhere in your environment, Claude Code uses it in preference to your subscription, and every session is billed to that API account instead of being covered by your plan.

This is worth checking even when nothing looks wrong, because nothing does look wrong. The key does not cause an error or a warning. Work continues exactly as before, and the only visible sign is the bill.

shell
echo $ANTHROPIC_API_KEY

If that prints anything, the key is the fault rather than the fix. Clear it, delete whatever line sets it in your ~/.zshrc or ~/.bashrc, then sign in against your subscription:

shell
unset ANTHROPIC_API_KEY
claude setup-token

Two other variables behave the same way, for the same reason: ANTHROPIC_AUTH_TOKEN and ANTHROPIC_BASE_URL both point Claude Code away from your subscription. Check for those too if the bill does not stop.

If you run other local MCP servers

Corey connects over HTTPS, so it is not affected by folder paths on your machine. Other servers usually are, and when one of them fails it can look like a general breakage.

  • Check the folders each one is configured with still exist. This is the first thing to test, and the most common cause.
  • Know which file you are editing. An extension keeps its own settings, separate from any manually added server list. Correcting the path in the manual list does not repair a broken extension, it just adds a second server alongside it.
  • Do not run two servers of the same kind. If a filesystem extension is enabled and a filesystem server is also configured manually, their tools have the same names and the results are unpredictable. Keep one.
  • Use full paths for commands. A server whose command is a bare npx, node or uvx can work in your terminal and fail from the app, because an app launched from the Dock or Start menu does not inherit your terminal’s PATH. Use /opt/homebrew/bin/npx rather than npx.

Note that Corey’s Desktop setup uses Cowork’s built-in file access, not the older Filesystem extension. If you still have that extension enabled from an earlier setup, it is a common source of this class of problem.

Reading the logs, if you need proof

On macOS, per-server logs are in ~/Library/Logs/Claude/. On Windows, look in %APPDATA%\Claude\logs\.

One thing to know before you read them: “Server started and connected successfully” does not mean the server is healthy. It only means the program was launched. It appears in failing runs too, which makes it easy to rule out the real cause by mistake.

The signal is a reply that never arrives. A working server answers a startup request within about a second:

shell
Message from client: method="initialize" id=0
Message from server: id=0 result

If you see the first line and not the second, the server stopped during startup. Messages about version negotiation, or about other sessions being unable to use the tools, are usually consequences of that same stop rather than separate problems.

Running Corey on a server

See Run Corey on a Hetzner VPS for the full setup. The problems specific to servers:

  • The service starts by hand but fails under systemd. A systemd unit does not run a login shell, so anything on your login PATH is missing. Give the unit the full path to claude and set COREY_HOME explicitly in the unit file rather than relying on the environment.
  • Doppler cannot find the project. Confirm the working directory in the unit matches where you ran doppler setup.
  • Check the service is actually running, not merely enabled: systemctl status corey.

Still stuck?

Email kristian@pressonetwork.com with:

  • what you were doing when it broke, and whether it worked before
  • the output of claude --version, and claude mcp list if you use the CLI
  • whether anything moved recently - a renamed folder, a new machine, a restored backup

That last one resolves more cases than the other two combined.

Related

Quick start - Claude DesktopQuick start - Claude Code CLIFix or reorganise an existing setupRun Corey on a Hetzner VPS

Questions, answered

Almost always something moved. If you renamed or moved your Corey folder, Cowork and the corey shell function are still pointed at the old location. Reopen the folder in Cowork, and update COREY_HOME in your shell file if you use the CLI. If you also run local MCP servers, a folder that no longer exists stops the whole server rather than just that folder, so every tool it provided disappears at once.
Claude Desktop only reads connector configuration when it starts. Closing the window is not enough, and neither is opening a new chat. Quit the app fully (Cmd+Q on macOS, or right-click the taskbar icon and Quit on Windows) and reopen it.
A local MCP server checks its folders at startup. If none of them can be reached it stops rather than starting with nothing, which is the safer behaviour, since tools that silently do nothing are worse than tools that are visibly absent. The visible symptom is only a disconnection notice, which does not mention the folder, so check the paths first.
An app launched from the Dock or Start menu does not inherit your terminal's PATH, so anything installed by Homebrew, nvm or a version manager is invisible to it. A command like npx or node is found in your terminal and not found by the app. Use the full path instead, for example /opt/homebrew/bin/npx.