Claude Projects vs Claude Code: Which to Use for What

Use a Claude Project when the work is thinking, reading and writing against a fixed set of material: a spec, a set of contracts, a research folder. Use Claude Code when the work is changing something on disk: reading a codebase, editing files, running the tests. A Project gives Claude context; Claude Code gives Claude hands. They are not rival versions of the same thing, and on most pieces of software work you end up using both, one after the other.

What each one is

A Claude Project lives in the Claude app. Anthropic’s help centre describes projects↗ (opens in a new tab) as self-contained workspaces with their own chat histories and knowledge bases: you upload documents, set project instructions, and every chat in the project starts with both. On Team and Enterprise plans a project can be shared with colleagues.

Claude Code is a different product. The Claude Code overview↗ (opens in a new tab) calls it an agentic coding tool that reads your codebase, edits files, runs commands and integrates with your development tools, and it runs in a terminal, in IDE extensions, in a desktop app and in the browser. Its standing instructions live in CLAUDE.md files in the repository, not in a settings panel.

• Where the context lives: Project knowledge and instructions in the Claude app, versus CLAUDE.md and the repository itself for Claude Code.
• What Claude can touch: in a Project chat, the conversation and whatever connectors you have enabled; in Claude Code, your files and your shell, within the permissions you grant.
• What comes out: answers, drafts and Artifacts from a Project; commits, changed files and test runs from Claude Code.
• Who can see it: a Project can be shared inside an organisation on Team and Enterprise; Claude Code’s instructions are shared the way the repository is, through version control.

A naming trap: Projects inside Claude Code

Since September 2026 the word means two things. Anthropic has redesigned projects↗ (opens in a new tab) and is rolling the new version out in beta, starting in Claude Code. There, a project is one ongoing conversation in which Claude splits the work into threads, runs them as parallel cloud sessions, and keeps project instructions and a shared project memory that every thread starts from.

The Claude Code documentation on Projects↗ (opens in a new tab) says this version is in beta on Pro and Max, not yet on Team or Enterprise, belongs to one user and cannot be shared, and runs at claude.ai/code, in the desktop app and in the mobile app rather than in the terminal CLI. Existing projects in chat keep working as they do; on Pro and Max, the help centre says they will be upgraded as the rollout reaches chat. The same page adds that the CLI’s claude project command, which manages local Claude Code state for a directory, is unrelated to either. The rest of this piece compares the Projects most people mean today, in the Claude app, with Claude Code as a tool.

When a Claude Project is the right tool

• The material is documents, not a repository: a product brief, interview notes, a policy, a pile of support tickets.
• You come back to the same material with new questions over weeks, and want every chat to start already briefed.
• Several people in the organisation need the same briefing and the same instructions.
• The output is prose: a spec, a plan, a reply, a summary, a first draft of a task list.
• Nobody needs Claude to run anything. It reads and writes text.

When Claude Code is the right tool

• The truth is in the code. A question like “where is the retry logic?” is answered by reading the repository, not a summary of it.
• The work ends in a change: a fix, a refactor, a new endpoint, an updated config.
• The work needs verification: run the tests, run the linter, start the app and look.
• The context changes daily. A repository is always current; a knowledge file uploaded last month is not.
• The job is long and multi-step, so you want an agent that plans, acts and checks rather than one answer at a time.

Claude Code is not only for code. Anything that lives as files, such as a docs site or a folder of data, suits it; we covered that in using Claude Code for non-coding tasks. Structuring the repository so it works well is in Claude Code project structure.

Two places for standing instructions

Both tools have an answer to “what should Claude know before it starts?”, and they are not the same answer. Project instructions are text you set in the project, applied to every chat in it. Claude Code reads CLAUDE.md; Anthropic’s memory documentation↗ (opens in a new tab) says it loads at the start of every session and recommends keeping each file under 200 lines, because longer files consume more context and reduce adherence. Alongside it, Claude Code keeps an auto memory of notes it writes itself, stored on your machine rather than in the repository.

Neither reads the other. A rule you put in project instructions — “we never ship on Fridays”, “prices are always shown ex VAT” — does not reach Claude Code in the repository, and a line in CLAUDE.md does not reach a chat in the Project. If both tools work on the same thing, the rule has to live in both places, or somewhere both can read.

Using both on the same piece of work

A common shape for a feature: think in the Project, build in Claude Code, and keep a shared list in between so the hand-over is not a copy-paste.

1. In the Project, with the product brief and customer notes as knowledge, work out the spec and break it into tasks, each small enough to finish and check.
2. Put those tasks somewhere both tools can reach, with a kind and a clear note: what, why, where.
3. In the repository, Claude Code picks up the next task, reads the relevant code, makes the change and runs the tests.
4. It records what it did against the task: the commit, what it checked, what it could not do.
5. Back in the Project, Claude reads the list to answer “what shipped this week?” or to draft release notes, without you pasting anything across.

The weak point is steps two and four. A Project’s knowledge is uploaded files, and the help centre notes that context is not shared across chats in a project unless it is added to the knowledge. Claude Code’s memory lives on your machine and in the repository. Without a shared list, you become the courier.

On fenbs, that list is a board. Connect Claude in the app with the Claude connector and Claude Code with one command, and both read and write the same tasks under your role, with their changes recorded as “Claude via” you. Both also read the board’s AI context with fenbs_get_context, which is the “somewhere both can read” for the rules above.

claude mcp add --transport http fenbs https://fenbs.ai/api/mcp

Then /mcp in Claude Code to sign in. What to put in CLAUDE.md so it works from the board by habit is in the Claude Code task-tracking workflow.