settings.json should traverse up to git root like CLAUDE.md does

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

When working in a monorepo with nested service directories, there's inconsistent behavior in how Claude Code discovers configuration files:

• CLAUDE.md: Traverses up the directory tree from cwd to the git repository root, loading all matching files along the way ✓
• settings.json: Only looks in {cwd}/.claude/settings.json, does NOT traverse up to git root ❌

This is problematic because I want to define shared hooks and settings at the monorepo root that apply to all services, but when I work from nested service directories (which is the common workflow), the settings aren't loaded.

Proposed Solution

settings.json should be discovered by traversing up to the git root, similar to how CLAUDE.md files are discovered.

When working in /my-monorepo/services/my-service/client/, Claude Code should:

1. Look for .claude/settings.json in the current directory
2. If not found, traverse up: ../, ../../, etc.
3. Stop at the git repository root
4. Load the first settings.json found (or merge all found, similar to CLAUDE.md behavior)

This would allow monorepo maintainers to define project-wide hooks/settings once at the repo root.

Alternative Solutions

Currently the workarounds are:

1. Duplicate .claude/settings.json in every service directory (maintenance nightmare, prone to drift)
2. Always start Claude Code from the repo root (inconvenient, forces unnatural workflow)
3. Use ~/.claude/settings.json (too global, applies to all projects, can't have project-specific settings)
4. Symlinks (fragile, doesn't work well across different systems/OS)

None of these are ideal compared to having proper directory traversal like CLAUDE.md.

Priority

High - Significant impact on productivity

This affects every session in a monorepo where you work from nested directories, requiring manual workarounds or degraded functionality.

Feature Category

Configuration and settings

Use Case Example

Example scenario in a typical monorepo:

/redox-services/                     # git root
├── .claude/
│   ├── settings.json                # PostToolUse hooks for prettier/eslint
│   └── CLAUDE.md                    # Project docs
├── services/
│   ├── customer-dashboard-ui/
│   │   └── client/                  # I work here 90% of the time
│   ├── api-gateway/
│   └── auth-service/
└── libraries/
    └── shared-utils/

Current behavior:

1. I navigate to /redox-services/services/customer-dashboard-ui/client (my usual working directory)
2. I start Claude Code: claude
3. Claude loads CLAUDE.md from repo root ✓
4. Claude does NOT load settings.json from repo root ❌
5. My PostToolUse hooks don't run when editing files
6. I have to manually run prettier/eslint after every edit

Desired behavior:

1. Same starting point: /redox-services/services/customer-dashboard-ui/client
2. Start Claude Code: claude
3. Claude loads both CLAUDE.md AND settings.json from repo root ✓
4. PostToolUse hooks run automatically on every edit ✓
5. Consistent developer experience across the entire monorepo

Additional Context

This inconsistency between CLAUDE.md and settings.json discovery creates a confusing developer experience. If CLAUDE.md can traverse up to git root, settings.json should follow the same pattern for consistency and to enable the monorepo use case.

Many modern development tools (ESLint, Prettier, TypeScript, etc.) traverse up to find configuration files, so this pattern is familiar to developers.