`earth ls` (and `earth +target`) fail from a subdirectory — must cd to project root

[gilescope]

What went wrong?

Running earth ls from a subdirectory of a project fails, even though an Earthfile exists at the project root:

$ tree
.
├── Earthfile
└── sub/

$ cd sub
$ earth ls
Error: unable to locate Earthfile under current directory

You have to cd back up to the directory containing the Earthfile for earth ls (and earth +target) to work. The lookup only checks the current directory, not ancestor directories.

Git already solves this problem — you can run git status from anywhere inside a repo and it walks up to find .git. earth should do the same, walking up to find the nearest Earthfile.

Repro

mkdir -p eb-test/sub
printf 'VERSION 0.8\nfoo:\n\tRUN echo hi\n' > eb-test/Earthfile
cd eb-test/sub
earth ls          # Error: unable to locate Earthfile under current directory
cd ..
earth ls          # +base / +foo  (works)

What should have happened?

earth ls and earth +target should walk up the directory tree to find the nearest Earthfile (like git, cargo, npm etc.), so they work from any subdirectory of a project.

Workaround: run from the root, or pass an explicit path, e.g. earth ls .. / earth ../+foo resolves the parent correctly.

What earthly version?

earth version dev-69dff834-cachemiss 69dff834 darwin/arm64; macOS 26.5.1

(also reproduces on released builds)

Other Helpful Information

Bare earth ls with no arg defaults to .; the resolver errors instead of ascending. Making the default resolve to the nearest ancestor Earthfile would fix both ls and target invocation.