Check Claude Code instruction scope across two client projects

Claude Code can load project instructions from several places at once. If you maintain two client projects, a fresh session in each directory lets you check which instruction files actually entered each context. The useful result is a pair of recorded file lists, not an assumption that sibling folders separate client information.

The big change

What changed: This guide turns Claude Code's documented instruction hierarchy into a repeatable comparison across two existing, authorized project directories. You record the files loaded at launch, then check whether a nested instruction file appears after a permitted file read.

Why it matters: A shared parent, personal instruction, import, rule or setting can affect both projects. /context shows loaded memory-file membership in the running session, so you can investigate an unexpected path before doing client work.

What to watch: Loaded instructions do not limit which files Claude can access or guarantee that it follows every instruction. Review the actual account, permissions, imports, hooks and data-use terms before sending any client content to the selected provider.

What you need

This procedure is for a developer with permission to inspect two existing client repositories and their Claude Code configuration. Obtain separate authorization to send the specific project content you plan to use to your chosen Claude account or provider. Permission to edit local files alone does not settle that decision. You need terminal access, Claude Code installed, an eligible account or provider, and a harmless existing file in a nested directory of one project. Check Anthropic's setup, cost and data-use documentation for the route you use.

The layout below shows the paths to identify; it is not a request to create new client projects. Replace every illustrative path in the commands with the corresponding real, authorized path. A parent CLAUDE.md is optional and should contain only instructions approved for both projects. The nested file and harmless document must already be suitable for the chosen account's data path.

AUTHORIZED_PARENT/
  CLAUDE.md                 optional shared instructions
  project-A/
    CLAUDE.md               A's project instructions
  project-B/
    CLAUDE.md               B's project instructions
    subdir/
      CLAUDE.md             B's nested instructions
      README.md             authorized, nonsensitive read target

1. Resolve the two project paths

Use either PowerShell or Bash. Set the variables to the two actual directories. These checks require existing paths, compare the resulting path strings, and confirm the B read target exists. PowerShell's Resolve-Path can preserve a symlink or junction alias; different strings alone do not establish distinct physical projects. Inspect links and junctions in both launch paths and their ancestor chains, follow their targets, and confirm A and B are genuinely distinct projects before continuing. Keep the paths, target checks and subsequent context lists in a private work record.

$a = (Resolve-Path -LiteralPath 'C:\actual\authorized\project-A' -ErrorAction Stop).Path
$b = (Resolve-Path -LiteralPath 'C:\actual\authorized\project-B' -ErrorAction Stop).Path
if (-not (Test-Path -LiteralPath $a -PathType Container)) { throw 'A must be an existing directory' }
if (-not (Test-Path -LiteralPath $b -PathType Container)) { throw 'B must be an existing directory' }
if ($a -eq $b) { throw 'A and B must be different directories' }
$target = Join-Path $b 'subdir/README.md'
if (-not (Test-Path -LiteralPath $target -PathType Leaf)) { throw 'Choose an existing authorized nonsensitive file in B/subdir' }
$a
$b
$target

a=$(realpath -- /actual/authorized/project-A) || exit 1
b=$(realpath -- /actual/authorized/project-B) || exit 1
test -d "$a" || { printf '%s\n' 'A must be an existing directory' >&2; exit 1; }
test -d "$b" || { printf '%s\n' 'B must be an existing directory' >&2; exit 1; }
test "$a" != "$b" || { printf '%s\n' 'A and B must be different directories' >&2; exit 1; }
target="$b/subdir/README.md"
test -f "$target" || { printf '%s\n' 'Choose an existing authorized nonsensitive file in B/subdir' >&2; exit 1; }
printf '%s\n' "$a" "$b" "$target"

If the projects are not siblings, record their actual ancestor chains independently. Do not infer a shared parent from the drawing.

2. Audit what could load before opening either project

For each resolved launch directory, inspect CLAUDE.md, .claude/CLAUDE.md, CLAUDE.local.md, AGENTS.md and .claude/AGENTS.md in that directory and every ancestor through the filesystem root. Also inspect the managed instructions for your operating system, ~/.claude/CLAUDE.md, user rules, and project .claude/rules/ files. The memory manual says discovered CLAUDE.md files concatenate; a nearer file does not erase an ancestor's text. A nested CLAUDE.md normally loads after Claude reads, writes or edits another file there. Path-scoped rules can load when a matching file is accessed.

These path-only commands give you an ancestor inventory without displaying file contents. Review any returned files under the relevant owner's authority. Repeat with both variables; on Bash, the loop covers both automatically.

foreach ($start in @($a, $b)) {
  $dir = [System.IO.DirectoryInfo]::new($start)
  while ($null -ne $dir) {
    Get-Item -LiteralPath $dir.FullName -Force | Select-Object FullName,LinkType,Target
    foreach ($name in @('CLAUDE.md', 'CLAUDE.local.md', 'AGENTS.md', '.claude/CLAUDE.md', '.claude/AGENTS.md')) {
      $candidate = Join-Path $dir.FullName $name
      if (Test-Path -LiteralPath $candidate -PathType Leaf) { $candidate }
    }
    $dir = $dir.Parent
  }
}

for start in "$a" "$b"; do
  dir=$start
  while :; do
    for name in CLAUDE.md CLAUDE.local.md AGENTS.md .claude/CLAUDE.md .claude/AGENTS.md; do
      test -f "$dir/$name" && printf '%s\n' "$dir/$name"
    done
    test "$dir" = / && break
    dir=$(dirname -- "$dir")
  done
done

Read the actual instruction files and their @path imports; relative imports resolve from the file that contains them. Follow any symlink or junction in each PowerShell launch path and ancestor chain, then audit both the named and target hierarchies that may affect the session. Check instruction-file symlink targets and claudeMdExcludes patterns. Inspect .claude/settings.json, .claude/settings.local.json, user and managed settings, any --settings or --setting-sources launch options, configured hooks, and the trust state of each project. CLAUDE_CONFIG_DIR can relocate the user configuration folder, so check it before assuming ~/.claude. Review what commands a hook could run before accepting workspace trust. An import outside the working directory can prompt for approval; a declined import will not appear as expected. The settings manual explains which layer supplies each setting and which project settings wait for trust.

Check the Project instructions choice in /config or its user/managed plugin setting. Current Claude Code documentation describes AGENTS.md as a conditional fallback when no project or ancestor CLAUDE.md or CLAUDE.local.md qualifies; claude-md-and-agents-md loads both. Direct AGENTS.md support depends on version and enabled plugin. Earlier versions and some settings could omit it, including the version-specific issue covered in BIG CHANGE's AGENTS.md feature-flag report. Use your actual version, setting and /context result instead of assuming it always loads.

Record --add-dir arguments and CLAUDE_CODE_ADDITIONAL_DIRECTORIES_CLAUDE_MD separately. --add-dir expands file access; by default it does not load that extra directory's CLAUDE.md. The environment switch enables instruction loading from added directories. Check auto memory with /memory as a separate channel: it can be shared across worktrees and subdirectories of one repository, and its storage location can be overridden. Inspect the actual location and content before interpreting the comparison. Never put credentials or unpublished client facts into sample instructions or the public record.

Before launch, check these environment values in the same shell you will use. A blank Bash value means unset or empty; PowerShell lists only variables present. These shell values do not rule out settings-file values, so confirm active settings inside each session.

Get-Item Env:CLAUDE_CONFIG_DIR,Env:CLAUDE_CODE_ADDITIONAL_DIRECTORIES_CLAUDE_MD -ErrorAction SilentlyContinue | Select-Object Name,Value

printf 'CLAUDE_CONFIG_DIR=%s\n' "${CLAUDE_CONFIG_DIR-}"
printf 'CLAUDE_CODE_ADDITIONAL_DIRECTORIES_CLAUDE_MD=%s\n' "${CLAUDE_CODE_ADDITIONAL_DIRECTORIES_CLAUDE_MD-}"

3. Start a fresh session in project A

Record claude --version and the exact launch command. Start a new process from A, without --resume or --continue. Accept trust only after the settings and hooks audit. Run /context before asking Claude to open B or any nested file. Record the exact paths under memory files and rules; use the list to check membership, not to infer injection order. Use /memory to inspect the displayed personal, project and auto-memory entries and their storage location. Then exit the session.

claude --version
Set-Location -LiteralPath $a -ErrorAction Stop
claude

claude --version
cd -- "$a" && claude

Inside Claude Code, /status identifies active setting sources, and /permissions displays current tool rules and their sources. Record those alongside the instruction list:

/context
/memory
/status
/permissions
/exit

Expect the applicable A and shared ancestor instructions to appear, subject to the audited settings and exclusions. A B-specific file should not be in A's launch hierarchy. If it appears through an import, link, added directory or another channel, record that mechanism. Its absence does not prove B's files are inaccessible.

4. Start a separate session in project B, then read one nested file

Use a new Claude Code process in B with the same installed version and account/provider route. Record /context and /memory before any nested read. Ask Claude to read only the exact approved harmless file. Confirm in the session that the read occurred, then run /context again and compare path membership. The manual's loading rule predicts that B's subdir/CLAUDE.md joins context after Claude accesses another file in that directory, unless a setting, exclusion or version-specific behavior changes the outcome.

Set-Location -LiteralPath $b -ErrorAction Stop
claude

cd -- "$b" && claude

Inside Claude Code, replace the read request only if your authorized target has a different relative path:

/context
/memory
/status
/permissions
Read only subdir/README.md. Tell me whether that exact file was read; do not open other files or display its contents.
/context
/exit

Claude Code may request a tool permission or propose another action. Approve only the exact authorized read and confirm the tool actually opened that file. A prompt response claiming to have read it is insufficient evidence by itself.

5. Compare the lists and resolve differences

Keep a private table with the resolved A and B paths, repository roots, Claude Code version, account/provider route, launch commands, trust state, settings sources, extra directories, instruction-file and rule paths, imports, auto-memory locations, and the three observed /context lists: A at launch, B before read, B after read. Mark each expected file present, absent or unexplained. Do not copy client instruction text into a public report.

If an expected file is absent, first verify the launch directory and the actual file path. Then check the Project instructions setting and plugin/version, claudeMdExcludes, --setting-sources, imports and external-import approval, rule path patterns, symlinks and the confirmed nested read. If an unexpected file appears, trace it through ancestor directories, user or managed instructions, imports, rules, hooks, additional-directory memory loading and auto memory. A shared ancestor or personal instruction may be intentional; its provenance and contents decide whether it belongs in both projects.

Change an instruction or setting only with the appropriate client's authority. Review the proposed diff, preserve existing constraints, and repeat both fresh-session observations after a change. If you cannot account for a path or do not have permission to inspect a contributing channel, pause client work and ask its owner or administrator to resolve that specific uncertainty.

The exercise is complete when you have two recorded launch lists, B's verified before/after nested-read list, and an explanation for every material unexpected path. It establishes observed instruction membership for those sessions. It does not establish a confidentiality boundary, file-access isolation, guaranteed obedience, or the exact order in which the model used those instructions. For inspecting and continuing an existing conversation, see our separate Claude Code session-context guide.

Account charges and usage limits depend on the plan, authentication and provider. Anthropic's cost guide is the place to check current terms. This article was prepared from documentation: BIG CHANGE did not inspect client files, run A/B Claude sessions, test a model result or measure time or cost.

Sources & further reading

• Anthropic, “How Claude remembers your project”: instruction scopes, imports, nested loading, AGENTS.md, rules, exclusions, added directories, auto memory and /memory. The exact options can change with Claude Code versions.
• Anthropic, “Settings files and precedence”: user, project, local and managed configuration, including /status, trust and hook settings.
• Anthropic, “Configure permissions”: /permissions displays active tool rules and their sources; instruction text itself does not enforce tool access.
• Anthropic, “Explore the context window”: /context shows the loaded memory files in a live session; the displayed membership does not prove injection order.
• Anthropic, setup, costs and data usage: confirm installation and account prerequisites; also read the separate cost and data-use terms for your route.