Using project binding in Claude Desktop

`</> Code` is Claude Code. But it never shows the approval prompt, so without approving in advance it silently falls back to Main.

Folder binding is known as a Claude Code thing, so people on Claude Desktop tend to assume it isn't for them. It is.

In one line. Desktop's </> Code is Claude Code. So .mcp.json folder binding works there unchanged. But the built-in Code doesn't show the approval prompt, so you have to approve in advance: and you must check the save target before starting.

What folder binding is and why it matters is in Folder binding. This page covers only the Desktop-specific part.

Why this is needed

Main, where saving points, is an account-wide pointer. Change it once in the console and every client on that account moves with it, the Desktop on your PC, the web, the CLI, all together. It can even change mid-conversation.

Binding is the only axis that escapes that. A connection with ?project= is pinned to its own project, so no matter how Main changes in the console, that connection's save target doesn't move.

Account Main  ──(global pointer)──> shared by every client, can change any time
?project=     ──(pinned to the connection)──> this one doesn't move

1. </> Code is Claude Code

The </> Code inside Claude Desktop is not a separate tool. It is Claude Code, embedded. So what works in Claude Code works here: folder binding included.

2. You can pick more than one folder

Desktop lets you select one or more working folders. Those become the session's working locations.

3. Put .mcp.json in the folder you picked

Create the project binding as .mcp.json in the selected folder and it works. The contents are identical to Claude Code's.

{
  "mcpServers": {
    "AiAkiv": {
      "type": "http",
      "url": "https://mcp.aiakiv.com/mcp?project=my-project-name"
    }
  }
}

Don't type the project name: copy it from the console: Console → Projects → Project management → 'MCP config for this project'. The reason and the steps are in Folder binding.

If you picked several folders, put it in the first one if you can. That reduces confusion about which folder's config was read.

4. ⚠ You must approve in advance

This is where people get stuck most often.

Desktop's built-in Code doesn't show the .mcp.json approval prompt. In the CLI you'd be asked "do you trust the MCP servers in this folder?"; the embedded one never asks. And an unapproved MCP server is silently skipped: no error, no warning.

So what happens? The AiAkiv tools are still there, because it falls back to the account connector (Main). Meaning only the binding quietly disappears, and the screen looks fine. That's why §8's check exists.

There are two ways to approve, and both write the same value to the same file.

Method A: the settings file directly

Put this in the working folder's .claude/settings.local.json.

{
  "enableAllProjectMcpServers": true
}

That auto-approves every MCP server in this project. To name servers individually, use enabledMcpjsonServers with an array of names.

{
  "enabledMcpjsonServers": ["AiAkiv"]
}

If you'd rather not edit the file, run claude once in that folder from the CLI.

cd working-folder
claude

A New MCP server found prompt appears. Approving there writes that value into the same .claude/settings.local.json: into enabledMcpjsonServers if you approve one, or enableAllProjectMcpServers: true if you approve all.

So approving once in the CLI means Desktop inherits that approval. Same result as method A, with no chance of a typo.

It's convenient to finish authentication (OAuth) at the same time. In the CLI: /mcp → pick AiAkiv → sign in via the browser. Authentication is once per account, and which project you land in is set by the folder's URL: one sign-in, many folders (Authentication).

5. How approval is decided

In order:

Condition Result
Listed in disabledMcpjsonServers Rejected
Listed in enabledMcpjsonServers or enableAllProjectMcpServers: true Approved
Otherwise Pending: a prompt in the CLI, silently skipped in the embedded Code

A server you once rejected stays in disabledMcpjsonServers. If you approved it and it still doesn't attach, check whether the name is stuck there.

6. The setup with no authentication at all: API keys

Everything so far is the OAuth setup: a sign-in window once, and from then on the system verifies identity for you.

But there's also a setup with no authentication step at all: issue an API key pinned to that project in the console and paste it into the config.

{
  "mcpServers": {
    "AiAkiv": {
      "type": "http",
      "url": "https://mcp.aiakiv.com/mcp",
      "headers": { "Authorization": "Bearer <your key>" }
    }
  }
}

Copy this snippet from the console too. In Project management → 'MCP config for this project', choose the client and format and it comes out with the key already in it. Don't type it.

  • No sign-in window. Authentication is already inside the key (Authentication). Nothing to authenticate with /mcp, no browser to open. paste it and it works.
  • The project is pinned into the key. Issue one key per project and each config goes to its own project without using ?project=. The check-target tool shows binding as "api-key": isomorphic to folder binding, and it doesn't move when Main changes in the console.
  • It doesn't remove the approval issue. §4 and §5 are about whether .mcp.json is read at all, so they still apply with a key. What disappears is the authentication step.

⚠ The key is your ID card. Leaking it means handing over access to your memory wholesale: don't commit the config file. The full minimum is in Key hygiene in Authentication.

To summarize:

OAuth API key
Authentication One sign-in window None: it's in the key
Project pinning Via ?project= In the key itself
Secrets to manage None The key: you're responsible for storing it

7. ChatGPT and ChatGPT classic take a different setup

Everything above (§1–§6) is about Claude. The OpenAI side branches differently.

  • ChatGPT classic attaches via an OAuth account connector. Register once on the web and it works in both web and app.
  • ChatGPT cannot use OAuth. It attaches via §6's project-pinned API key.
  • The two setups can sit side by side, but then you must register them under different MCP server names (global AiAkiv / folder AiAkiv-proj). With the same name there's no way to say which one to use.

Steps and cautions are collected separately → Connecting ChatGPT

8. ⚠ Always check the save target before you start

As said above, a failed binding makes no sound. Checking is the only way to notice. Ask your AI before you start work.

where are you saving right now?

The AI calls get_save_target and reports back. Two things to look at.

  • binding is "folder": pinned via ?project=. If you attached with an API key it shows "api-key": also pinned.
  • No (Main) suffix on the project name: a suffix means it's following the global Main, so the binding didn't take.

If binding: "main" or the name carries (Main), go back to §4's approval.

Every value binding can take, and what each means, is in Confirming it attached in Folder binding.

Common problems

  • The tools are there but it saves to the wrong project. Approval didn't happen, so it fell back to the account connector. Check §4.
  • It works in the CLI but not in Desktop. The CLI gets approval through a prompt and Desktop can't. That's exactly the difference. Approve once in the CLI (method B) and both work.
  • I picked several folders and don't know which config was read. Put it in the first folder per §3, and check the actual target per §8.
  • These steps don't match ChatGPT or ChatGPT classic. Their setup differs. See §7 and go to Connecting ChatGPT.
  • It says the project name can't be found. Names are looked up only among projects you own. It may be a typo, or a project on a different account. Copy it from the console.
Full index → Docs View as Markdown