### Preflight Checklist - [x] I have searched [existing requests](https://github.com/anthropics/claude-code/issues?q=is%3Aissue%20label%3Aenhancement) and this feature hasn't been requested yet - [x] This is a single feature request (not multiple features) ### Problem Statement I use a git bare repo + worktree workflow for managing large enterprise projects. My project monorepo already has a committed .claude/ setup for team use (shared commands, project context). The current workflow requ

[Feature Request]: Bare Git Repository .claude Config Support

Status Closed — not planned

Maintainer reply None cached

Activity 5 comments · opened Apr 3, 2026 · closed May 12, 2026

Preflight Checklist

[x] I have searched existing requests and this feature hasn't been requested yet
[x] This is a single feature request (not multiple features)

Problem Statement

I use a git bare repo + worktree workflow for managing large enterprise
projects. My project monorepo already has a committed .claude/ setup
for team use (shared commands, project context).

The current workflow requires me to manually create .claude config in
every new worktree for personal commands (like PR creation, task
management). Since worktrees are ephemeral and created per branch,
this is impractical. There is no layer between the project-committed
.claude/ and the global ~/.claude/ for personal, project-specific config.

Proposed Solution

Claude Code should recognize a .claude/ folder placed in the bare repo
root as a valid personal config layer. Since bare repo has no working
tree, this config can never be accidentally committed — making it
naturally personal and machine-specific.

New config lookup chain:
<worktree>/.claude/ ← project team config (existing)
<bare-repo-root>/.claude/ ← NEW personal project config
~/.claude/ ← global personal config (existing)

Commands and CLAUDE.md from all layers should be merged.

Alternative Solutions

Symlinks: Break on git pull/checkout when project .claude/ is committed
~/.claude/commands/: Works but pollutes global config with

project-specific commands, no clean separation per project

Committing personal config: Not viable, these are personal workflow

tools not meant for team sharing

Priority

High - Significant impact on productivity

Feature Category

Configuration and settings

Use Case Example

My file structure:

my-app-bare/          ← git bare repo
  .claude/            ← WANT this to work for personal commands
    commands/
      create-pr.md    ← GitHub PR with my personal standards
      clickup-task.md ← ClickUp task with my formatting
  main/               ← worktree (main branch)
  stage/              ← worktree (stage branch)
  feature/
    auth/             ← worktree
    jwt/              ← worktree

Each worktree already has project's committed .claude/ (team config).
I need my personal commands available in ALL worktrees automatically
without committing them or duplicating them per worktree.

Additional Context

Technical note: Bare repo root can be detected from any worktree via:
git rev-parse --git-common-dir
This is the same mechanism git itself uses internally. Claude Code
could use this to walk up and find bare repo .claude/ automatically.

This workflow (bare repo + worktrees) is increasingly common among
senior developers managing large, long-lived enterprise projects with
multiple parallel feature branches.

View original on GitHub ↗

5 Comments

github-actions[bot] · 6 months ago

Found 3 possible duplicate issues:

This issue will be automatically closed as a duplicate in 3 days.

If your issue is a duplicate, please close it and 👍 the existing issue instead
To prevent auto-closure, add a comment or 👎 this comment

🤖 Generated with Claude Code

kaushal248 · 6 months ago

This is NOT a duplicate of the listed issues:

#34437 is about sharing memory/history across worktrees — different concern
#29909 is closed and proposed origin-URL keyed config in ~/.claude/ — different location approach
#31155 proposes gitignored local-skills inside the worktree — still per-worktree, not solved for ephemeral worktrees

My proposal uniquely leverages the bare repo root as a natural,
architecture-level personal config boundary. Since bare repos have
no working tree, config placed there can NEVER be accidentally
committed — no .gitignore needed. This is a fundamentally different
and cleaner approach for the bare repo + worktree workflow.

github-actions[bot] · 5 months ago

Closing for now — inactive for too long. Please open a new issue if this is still relevant.

sepsol · 5 months ago

I have the same concern as you and would like to see a solution like your proposal to it.

But let me share a pattern worth investigating for anyone using git worktrees (especially bare-repo layouts) who wants .claude/ updates to propagate across worktrees and teammates without waiting on feature-branch merges.

Layout:

my-project/
├── .bare/                  <-- the actual repository
├── .git                    <-- file pointing at .bare
├── main/                   <-- worktree
│   └── .claude/            <-- submodule → claude-config repo
├── feature-a/              <-- worktree
│   └── .claude/            <-- same submodule
└── hotfix/                 <-- worktree
    └── .claude/            <-- same submodule

The idea: Track .claude/ as a git submodule pointing at a dedicated claude-config repo, with branch tracking enabled:

[submodule ".claude"]
    path = .claude
    url = <your claude-config repo>
    branch = main

Updates flow: edit .claude/ from any worktree → push to the claude-config repo's main. Teammates pick it up via git submodule update --remote --merge, regardless of which parent branch they're on.

Automating the sync with hooks: to avoid relying on teammates remembering the command, commit post-merge, post-checkout, and post-rewrite hooks to a tracked .githooks/ directory and have everyone run git config core.hooksPath .githooks once (or wire it into a setup script / Husky). Each hook runs:

git submodule update --init --remote --merge .claude

A pre-push hook that warns on uncommitted/unpushed changes in .claude/ is also worth adding — prevents pushing a parent pointer at a SHA that only exists on your laptop.

Per-branch local instructions still work via gitignored *.local* files and CLAUDE.local.md. For personal cross-worktree prefs, use @~/.claude/... imports. And for org-wide overrides shared across multiple projects, teammates can import from a common parent directory: @~/organization-parent-directory/.claude/....

Caveats:

Parent repo still records a submodule SHA, so periodically commit pointer bumps on main to keep git status clean and fresh clones reproducible.
CI needs --recurse-submodules and a decision on whether to use the recorded SHA (reproducible) or live main (fresh).
Worktree-to-worktree on the same machine still requires push + pull through the submodule remote.

Lighter alternative for solo/small setups: a dedicated claude-config branch checked out as its own worktree, symlinked into each feature worktree's .claude/. Same single-source-of-truth, less tooling overhead — but doesn't scale to teammates as cleanly.

Curious if others have tried either approach and how it held up.

github-actions[bot] · 3 months ago

This issue has been automatically locked since it was closed and has not had any activity for 7 days. If you're experiencing a similar issue, please file a new issue and reference this one if it's relevant.