Handles are keyed on the project NAME, not a project identity, so a handle replayed in another clone resolves "exact" against the wrong tree #151

New issue

Closed

opened 2026-09-05 12:54:43 +02:00 by buildagent · 0 comments

buildagent commented

2026-09-05 12:54:43 +02:00

Member

Found by a production-readiness review.

crates/core/src/handle.rs:104 encodes:

{project}{US}{path}{US}{identity_name}{US}{kind}{US}{exact}.{shape}

{project} is the project name. "primary" is "primary" in every workspace, every clone and every worktree.

So a handle minted in one clone and replayed in another resolves status: "exact" against a different tree. Two clones of the same repo satisfy all four remaining fields for essentially every symbol — and worktrees of the same repo are the normal case for this workflow, not an exotic one.

The handle system's whole promise is that exact means this is the same thing you were looking at. Across clones it currently means a thing with the same name exists here.

Prior art in this repo

I031's review already caught the adjacent bug — a wrong-project handle stamp on auto-routed absolute paths. This is the same class one level down: the discriminator is a display name rather than an identity.

Care

Whatever identity is chosen must not be derived from canonicalize().unwrap_or(raw) — a key derived that way moves when the disk moves, which this project has already been bitten by. It also must survive a legitimate move of the checkout, or exact degrades to missing for every handle whenever someone relocates their repo.

I031/I032 (stable handles, handle v2)

🤖 Generated with Claude Code

https://claude.ai/code/session_01K1zj5VcFJvJt3pQxe9259K

Found by a production-readiness review. `crates/core/src/handle.rs:104` encodes: ``` {project}{US}{path}{US}{identity_name}{US}{kind}{US}{exact}.{shape} ``` `{project}` is the project **name**. `"primary"` is `"primary"` in every workspace, every clone and every worktree. So a handle minted in one clone and replayed in another resolves `status: "exact"` against a different tree. Two clones of the same repo satisfy all four remaining fields for essentially every symbol — and worktrees of the same repo are the *normal* case for this workflow, not an exotic one. The handle system's whole promise is that `exact` means *this is the same thing you were looking at*. Across clones it currently means *a thing with the same name exists here*. ## Prior art in this repo I031's review already caught the adjacent bug — a wrong-project handle stamp on auto-routed absolute paths. This is the same class one level down: the discriminator is a display name rather than an identity. ## Care Whatever identity is chosen must not be derived from `canonicalize().unwrap_or(raw)` — a key derived that way moves when the disk moves, which this project has already been bitten by. It also must survive a legitimate move of the checkout, or `exact` degrades to `missing` for every handle whenever someone relocates their repo. ## Related - I031/I032 (stable handles, handle v2) 🤖 Generated with [Claude Code](https://claude.com/claude-code) https://claude.ai/code/session_01K1zj5VcFJvJt3pQxe9259K

buildagent referenced this issue

2026-09-05 17:48:57 +02:00

On Windows a canonicalized project root and an env-derived one are two identity keys for one directory, and the disclosure names a project the caller cannot match #159