[BUG] Memory written to wrong project key + system-prompt cwd doesn't match actual cwd

Preflight Checklist

• [x] I have searched existing issues and this hasn't been reported yet
• [x] This is a single bug report (please file separate reports for different bugs)
• [x] I am using the latest version of Claude Code

What's Wrong?

Summary

Two related bugs that compound: (1) auto-memory files are being written to a project-key directory that doesn't match the current working directory, and (2) the model-facing system prompt reports a stale Primary
working directory that doesn't match the shell's actual pwd. Together they make the model confidently answer questions about the wrong project.

## Environment

• Claude Code: v2.1.118
• Model: Opus 4.7 (1M context), Claude Max
• OS: macOS Darwin 25.4.0
• Auto mode: on

## Bug 1 — memory project-key drift

I work on two projects under ~/Downloads/SAME/Personal/: foofi and greenscreen. The foofi auto-memory ended up under the greenscreen project key:

```
$ ls ~/.claude/projects/-Users-sahil-Downloads-SAME-Personal-foofi/
.session-aliases # no memory/ subdir at all

$ ls ~/.claude/projects/-Users-sahil-Downloads-SAME-Personal-greenscreen/memory/
MEMORY.md
project_foofi.md # ← foofi's project memory, in the wrong key
reference_asdlc.md
reference_design_md.md
```

A foofi-keyed project dir exists (Apr 27 11:51) but is empty of memory. The greenscreen-keyed dir holds the actual foofi memory files. I had to manually mv them to the correct key.

Expected: a session launched from cd ~/Downloads/SAME/Personal/foofi should read/write memory under the foofi project key.
Actual: memory is being written/read under the greenscreen project key, even when the session is launched from foofi.

My best guess at the cause: the project key gets bound to the directory the very first session was launched from and isn't recomputed on subsequent launches or cd.

## Bug 2 — system-prompt cwd doesn't match shell cwd

In the same session, the Claude Code UI header showed the session running in ~/Downloads/SAME/Personal/foofi (screenshot below), and pwd returned /Users/sahil/Downloads/SAME/Personal/foofi/foofi_desktop.
But the system prompt I received said:

> Primary working directory: /Users/sahil/Downloads/SAME/Personal/greenscreen

So the model is being told it's in greenscreen while the user is actually in foofi. I trusted the system-prompt header over pwd and gave the user wrong answers about which project they were working on — exactly
the failure mode this header is supposed to prevent.

Expected: Primary working directory in the system prompt matches pwd at session launch.
Actual: it lags / points at a different project.

## Impact

• The model loses track of which project it's in.
• When the user asks about "the project" or "what's next?", the model can pivot to a different repo's code and pretend it's relevant — wasted tokens and trust.
• Auto-memory written this session lands in the wrong project key, so future sessions launched from the correct project don't see it.
• The user has to manually inspect ~/.claude/projects/ and move files between project-key dirs, which is not a documented user-facing operation.

## Reproduction

I don't have a clean repro because the bad state is already on disk, but the steps appear to be:

1. Launch Claude Code from project A
2. In a later session, launch Claude Code from project B
3. Observe: memory writes from session B land under A's project key; system prompt may still report A as the primary working directory

Happy to help reproduce with a fresh shell if useful — reach out.

What Should Happen?

## Request

• Recompute the project key from the actual launch cwd each session, not from a cached/first-time value.
• Make the system prompt's Primary working directory field authoritative — derive it from pwd at the moment the system prompt is rendered.
• Either way, surface the project-key path somewhere in /help or /status so users can sanity-check which key their memory is being written to.

Error Messages/Logs

Steps to Reproduce

dont know

Claude Model

Opus

Is this a regression?

Yes, this worked in a previous version

Last Working Version

_No response_

Claude Code Version

2.1.118

Platform

Anthropic API

Operating System

macOS

Terminal/Shell

iTerm2

Additional Information

<img width="463" height="221" alt="Image" src="https://github.com/user-attachments/assets/61777aac-6a39-4791-96bd-2c46d55edaef" />