Blog / claude code
Set up Claude Code for a team in five minutes
Commit one shared instruction file, keep team settings apart from personal ones, sign everyone in on their own plan, then check it with one question.
On this page
- How to set up Claude Code for a team, minute by minute
- A shared CLAUDE.md: a 12-line starter
- Shared settings vs personal settings in Claude Code
- Sign in on your own plan, then check it works
- If a teammate uses Codex or another agent
- Common problems when setting up Claude Code for a team
- When this is not enough
- Where Joxo fits
- Frequently asked questions
- Does every teammate need their own Claude plan?
- Should CLAUDE.md be committed to git?
- Can Claude Code and Codex share one instruction file?
A small team needs three things to share Claude Code on one repository: a committed CLAUDE.md that every session reads, team settings kept apart from each person's own, and everyone signed in on their own plan. Finish with a one-question check that every agent gives the same answers, and the whole setup fits in five minutes.
This is for a small team with no admin: one person owns the repository, and everyone has Claude Code on their own machine.
How to set up Claude Code for a team, minute by minute#
| Minute | Who | What they do | Done when |
|---|---|---|---|
| 0 to 2 | Repo owner | Writes CLAUDE.md from the starter below and commits it | The file is on main |
| 2 to 3 | Repo owner | Commits the team settings; keeps personal settings out of git | git status is clean |
| 3 to 4 | Each teammate | Pulls main, starts Claude Code in the repo, signs in with their own account and trusts the folder | The session opens in the repo |
| 4 to 5 | Each teammate | Asks the check question | Every agent gives the same answers |
Order matters: a session started before the file is on main has none of the rules, and will not notice.
A shared CLAUDE.md: a 12-line starter#
Claude Code reads CLAUDE.md at the start of every session. Commit one at the root of the repository, and every teammate's agent starts from the same rules. Here is a starter to edit:
# Shop: rules for every agent on this project
- Read this file and DECISIONS.md before you start work.
- Run the app with `npm run dev` and the tests with `npm test`.
- One task, one branch, named `<person>/<task>`. Never commit to main.
- Commit small. Add files by name; never `git add -A`.
- Do not edit package-lock.json, db/migrations/ or .env files unless asked.
- Changing an API shape, a schema or a shared function is its own task.
- A decision others will depend on: add one dated line to DECISIONS.md.
- Blocked? Write the question with a default answer, then do other work.
- Before a pull request: rebase on origin/main and run the full test suite.
- Never print, copy or commit secrets, tokens or keys.
- Unsure what "done" means? Ask the person who gave you the task.Keep it short, and use your real script names: "run the tests" without a command is a guess.
Shared settings vs personal settings in Claude Code#
Claude Code keeps two kinds of project settings apart. .claude/settings.json is shared: commit it with the repository. .claude/settings.local.json is for one person on one machine. When Claude Code creates the personal file itself, it keeps it out of git for you; if you create it by hand, add it to .gitignore yourself.
What goes where:
| Shared, committed | Personal, kept out of git |
|---|---|
| Commands every session may run without asking, such as the tests and the linter | Your theme, editor and notification choices |
| Commands no session should run, such as a deploy or dropping a database | Anything that names your account, a token or a path on your machine |
| Folders the agent should never edit | Extra permissions only you are comfortable with |
One rule covers most mistakes: if a setting needs a secret, it is personal. Never put a key or a token in a committed file, even for a minute, because it stays in the history.
Personal habits, such as "keep answers short" or "explain before you edit", belong in your own user-level instructions, ~/.claude/CLAUDE.md, not in the team's file.
Sign in on your own plan, then check it works#
Each teammate signs in with their own account, on their own plan. Do not share one login: nobody can then tell whose agent did what.
Then each person asks their agent the same question, before it changes anything:
Without changing anything: what is this project, how do I run the tests,
what branch name would you use for a task called "csv export", and which
files are you told not to edit?Every agent should give the same four answers. If one does not, its session did not load the file; see the first common problem below.
A second, quicker check: ask the agent to run the tests. If it asks permission every time, add the test command to the allow list in the shared settings, and nobody has to approve it again once they trust the folder.
If a teammate uses Codex or another agent#
Codex reads AGENTS.md. Recent versions of Claude Code read AGENTS.md too, but only when the project has no CLAUDE.md. To keep a CLAUDE.md for Claude-only rules, put the shared rules in AGENTS.md and make CLAUDE.md import it:
@AGENTS.md
## Claude Code only
- Use plan mode for anything under src/billing/.Claude Code pulls the imported file in when the session starts, so both tools follow one set of rules. We cover the details in how to share context between Claude Code and Codex. Cursor, OpenCode and Copilot CLI read AGENTS.md as well. Gemini CLI reads GEMINI.md unless its settings tell it to read AGENTS.md. Whichever file a tool reads, point it at the same rules; the glossary has the short version.
Settings do not travel between tools. The permission list you wrote for Claude Code means nothing to another agent, so whoever uses it sets the same limits there.
Common problems when setting up Claude Code for a team#
- The agent ignores the rules. It was started outside the repository, or before the pull. Restart it inside the repository.
- A trust question on first open. Claude Code asks whether you trust a folder the first time it opens it. Answer it at the keyboard. Until you do, the shared allow list does not apply, so the agent keeps asking before it runs the tests.
- A setting does not apply. Check the file is valid JSON. Your personal
.claude/settings.local.jsonwins over the shared file, so check yours for the same key. Allow and deny lists from both files are combined rather than replaced. Restart the session after any change. - A new worktree has no
.env. Untracked files do not come along. Claude Code reads a.worktreeincludefile listing git-ignored files to copy into each new worktree; more in running Claude Code sessions in parallel. - The file keeps growing. Move anything stable and long, such as the architecture, into its own document and link to it from the instruction file.
When this is not enough#
Five minutes sets up the rules. It does not tell anyone's agent what the others are doing right now, what a teammate's agent decided an hour ago, or which task is already taken. For that you need a shared task list and a decision log that every agent reads; we describe one in how to coordinate AI coding agents across a team, and how to stop two AI coding agents editing the same files covers the collisions.
And if your company needs central billing, single sign-on or admin controls, this is the wrong guide. Those are organization settings with their own setup.
Where Joxo fits#
If the team also wants one task board for everyone's agents, and a team chat where agents say what they finished and ask what only a person can decide, Joxo adds them with one line pasted into each person's agent, on the plan each person already has. Invite a teammate and they get a line with a code that joins them to the same project, whether they use Claude Code, Codex or Cursor. The setup page has the steps for each agent, and the FAQ answers the usual questions.
Frequently asked questions#
Does every teammate need their own Claude plan?#
Yes. Each person signs in to Claude Code with their own account. Sharing one login between people mixes everyone's sessions and settings, and makes it hard to tell whose agent did what. What the team shares is the repository: the instruction file, the team settings and the code. That is enough for every agent to follow the same rules.
Should CLAUDE.md be committed to git?#
Yes, the project's file should be. It holds the rules every session needs: how to run the app and the tests, how to name branches, and which files not to touch. Committing it means every teammate's agent reads the same rules, and a change to them is reviewed like a change to the code. Keep personal preferences in your own user-level instructions.
Can Claude Code and Codex share one instruction file?#
Yes. Codex reads AGENTS.md. Claude Code reads CLAUDE.md, and recent versions fall back to AGENTS.md only when a project has no CLAUDE.md. To keep both, put the shared rules in AGENTS.md and make CLAUDE.md import it with an @AGENTS.md line, adding anything only Claude Code needs below it. Both agents then follow the same rules from one source.