Reproduction steps

1. Create a directory "foo" with the following structure:

$ find foo
foo
foo/foo
foo/foo/test.txt
foo/test.txt
foo/root.txt
$ cat foo/test.txt
asd
$ cat foo/foo/test.txt
bar

A real example of a directory structure like this would be if you have a project containing a Rust workspace with a crate of the same name ("foo" in this case). Both would have a Cargo.toml (equivalent to test.txt in the example).

2. Open it in zed: zed foo
3. Open Zed agent and ask the model to read the file "test.txt" at the project root

Current vs. Expected behavior

Current behavior:

1. Model issues a read_file tool call with {"path": "foo/test.txt"}. This is faithful to the tool definition: "the first component of the path should always be a root directory in a project."
2. Zed returns the contents of the file test.txt in the subdirectory foo, instead of the project root, likely a heuristic to workaround invalid tool calls which exclude the root directory name
3. Because of this "shadowing", the model is in fact unable to read the corresponding file in the project root

Expected behavior:

It is expected that the tool behaves consistently. If read_file({"path":"foo/root.txt"}) returns the contents of the file root.txt in the project root, then replacing root.txt with test.txt should cause it to read the sibling file test.txt and not something in a subdirectory of the same name.

Zed version and system specs

Zed: v1.1.7+stable.268.c17f25cd782edffab64b7c4167abfa44f865b125 (Zed)
OS: macOS 26.4.1
Memory: 64 GiB
Architecture: aarch64

Attach Zed log file

No response

Relevant Zed settings

No response

Relevant Keymap

No response

(for AI issues) Model provider details

No response

If you are using WSL on Windows, what flavor of Linux are you using?

None