Using Claude Code and GitHub Copilot on the Same Project

You can use Claude Code and GitHub Copilot on the same project without either getting in the other’s way, and many people do: Copilot for completions and quick edits inside the editor, Claude Code in a terminal for longer tasks. Three things make it work. Keep one set of project rules that both read, rather than two files that drift apart. Decide which kind of task goes to which tool, so you are not asking both the same question. And never let the two agents edit the same files at the same time; give each its own task and, for anything long, its own worktree. A shared list of work ties it together. If you are still choosing between them, the comparison is in Claude Code vs GitHub Copilot; this post assumes you have both.

Which files each one reads

The instruction files are where two tools on one repository most often disagree, usually without anyone noticing. Here is what each reads today, according to its own documentation.

• Claude Code reads CLAUDE.md, and Anthropic’s memory documentation↗ (opens in a new tab) says it reads AGENTS.md instead when there is no CLAUDE.md or CLAUDE.local.md in the working directory or above it. With both present it reads only CLAUDE.md, unless CLAUDE.md imports the other file with @AGENTS.md.
• Copilot in VS Code reads .github/copilot-instructions.md and AGENTS.md, plus *.instructions.md files whose applyTo pattern matches. VS Code’s custom instructions page↗ (opens in a new tab) adds that sessions using the Claude agent read CLAUDE.md, and that instruction sources are additive: do not rely on any order to settle a conflict.
• Copilot on GitHub accepts AGENTS.md files anywhere in the repository, with the nearest one taking precedence, or, as GitHub’s guide to repository instructions↗ (opens in a new tab) puts it, a single CLAUDE.md or GEMINI.md at the root.

The practical reading: if the same rule sits in CLAUDE.md and in copilot-instructions.md, a Copilot session that loads both gets it twice, and the day someone edits one copy, it gets two versions. The full table for every assistant is in AI context files compared.

Keep one source of rules

Put the rules in AGENTS.md, which both tools understand. Make CLAUDE.md an import plus anything only Claude needs. Keep copilot-instructions.md short or leave it out: with AGENTS.md in place, Copilot already has the project rules.

AGENTS.md                         # the rules: build, test, layout, never-touch, how work is tracked
CLAUDE.md                         # @AGENTS.md, then Claude-only lines (hooks, subagents)
.github/copilot-instructions.md   # optional: only what is Copilot-specific
.mcp.json                         # shared MCP servers for Claude Code (claude mcp add --scope project)
.vscode/mcp.json                  # the same servers for Copilot in VS Code

@AGENTS.md

## Claude Code only
- Use the test-runner subagent for the full suite; do not run it inline.

The MCP files are the one place duplication is unavoidable, because each tool reads its own format. Keep the server list identical in both and review them together; a board, a database or a browser tool should be reachable from either agent or from neither.

Split the work by where it happens

The two tools overlap a great deal, so the split is a habit you choose, not a rule the tools enforce. One that works for many people:

• Copilot, in the editor: completions as you type, a quick question about the file in front of you, a small edit you want to watch happen, a fix you will review line by line in the diff.
• Claude Code, in a terminal: a task that runs for a while and touches many files, a refactor you want planned first, anything you script or run in CI, anything that needs a long chain of shell commands.
• Either, but not both: a given task. Whoever picks it up owns it until it is finished or handed back.

Hand-offs between the two are normal: Claude Code does the refactor, you finish the edges in the editor with Copilot. What makes a hand-off work is that it is written down somewhere both can read. Neither tool can see the other’s conversation, so “carry on from where Claude got to” means nothing to Copilot unless where Claude got to is in a commit message or a comment on the task. Ask the first agent to write that note before it stops, in a sentence or two: what changed, what is left, what it was unsure about.

The split also keeps review sane. Copilot’s changes arrive where you are already looking. Claude Code’s arrive as a batch, so they deserve a proper look at the diff, or a pull request, before they are merged. Claude Code in VS Code covers running Claude from inside the editor if you would rather have both in one window.

Claude inside Copilot

There are two ways Claude turns up inside Copilot itself, and neither is the same as running Claude Code.

• A Claude model in Copilot’s picker. GitHub’s supported models list↗ (opens in a new tab) includes several Anthropic Claude models, and an organisation or enterprise administrator may need to enable each one. This is still Copilot’s agent, reading Copilot’s instructions and tools, with Claude doing the reasoning. Your Claude Code settings, permissions and hooks do not apply.
• Anthropic Claude as a coding agent on GitHub. GitHub’s page on third-party coding agents↗ (opens in a new tab) lists Anthropic Claude and OpenAI Codex, in public preview on paid Copilot plans once enabled. You assign an issue or give a prompt from the Agents tab, an issue, a pull request, GitHub Mobile or VS Code, and it opens a pull request and asks you to review it.

Both are useful. Neither reads your local Claude Code configuration, so rules that must hold everywhere belong in AGENTS.md, not only in CLAUDE.md or .claude/settings.json.

Keep two agents out of the same files

The real risk of running two agents on one project is not that they disagree about style. It is that both edit payment.ts in the same working tree, each reads the other’s half-finished change as the current state, and you get a mess neither of them made on purpose.

• One task, one agent. Before starting, the agent says which task it has taken; the other does not touch it.
• Long Claude Code tasks get their own worktree. Anthropic’s worktrees guide↗ (opens in a new tab) covers claude --worktree <name>, which starts the session in a separate checkout, so your editor and Copilot keep the main one.
• Commit, or at least stash, before switching agents on the same checkout. A clean tree is the only way to see who changed what.
• Do not point both at the same branch in the background. If Copilot’s cloud agent or the Claude agent on GitHub is working an issue, leave that branch to it until the pull request arrives.

One list of work for both

Copilot’s session list and Claude Code’s transcripts are each visible only to the tool that made them, so neither can tell the other what is taken. A board both can reach over MCP can. On fenbs, Claude Code and Copilot connect to the same address, each signs in as you with the scopes you tick, and the board’s History records which assistant made each change. Put the rule in the shared AGENTS.md, so both follow it:

## The board
- Before starting: fenbs_get_context, then fenbs_list_items for In Progress.
- A task in In Progress belongs to whoever moved it there. Do not work on it.
- Taking a task: move it to In Progress and comment which assistant you are
  and what you will change. File it first with fenbs_create_item if it is new.
- Finishing: set testStatus and testNotes, comment the commit, move it to Completed.

If people pre-approve tasks for AI, fenbs_next_approved_task does the claiming for you: it hands out the most urgent approved task and holds it for that assistant for a few hours, so two never take the same one. The routine for Claude Code in particular is in a task-tracking workflow for Claude Code.