Opening a non-Git parent directory that contains several Git projects currently performs recursive instruction discovery through every project. A user asking only to list available projects pays the cost of walking all their source, environments, and data before open_workspace returns.
I reproduced this on macOS with the packaged 1.0.8 runtime: server-side opens of the parent took 26.654 and 86.737 seconds. The same traversal remains in the v1.1.0-beta.4 sources. Opening a selected small project was fast. A local change that recognizes a non-Git parent containing at least two immediate Git markers and discovers instruction files only at the parent/immediate-project level reduced the parent open to well under a second in local interface checks. Public-network timings are separate and are not a performance guarantee.
This overlaps the reported symptom in #90 and the bounded-discovery proposal in #197. The narrower proposal here is to preserve complete nested instruction discovery when a concrete Git project is opened, while treating a multi-project parent as a catalogue. It does not impose a time/file budget on discovery inside a selected repository. The host should open the selected project before operating in its contents.
I will submit a focused PR with a regression that fails on the existing implementation and verifies both shallow parent discovery and complete selected-project discovery. The parent/root instructions, configured allowed roots, OAuth checks, and path containment stay unchanged. A Git marker is used as a lightweight boundary signal, not as a claim that every directory is a valid repository; unrecognized parent layouts retain current behavior.
Opening a non-Git parent directory that contains several Git projects currently performs recursive instruction discovery through every project. A user asking only to list available projects pays the cost of walking all their source, environments, and data before
open_workspacereturns.I reproduced this on macOS with the packaged 1.0.8 runtime: server-side opens of the parent took 26.654 and 86.737 seconds. The same traversal remains in the v1.1.0-beta.4 sources. Opening a selected small project was fast. A local change that recognizes a non-Git parent containing at least two immediate Git markers and discovers instruction files only at the parent/immediate-project level reduced the parent open to well under a second in local interface checks. Public-network timings are separate and are not a performance guarantee.
This overlaps the reported symptom in #90 and the bounded-discovery proposal in #197. The narrower proposal here is to preserve complete nested instruction discovery when a concrete Git project is opened, while treating a multi-project parent as a catalogue. It does not impose a time/file budget on discovery inside a selected repository. The host should open the selected project before operating in its contents.
I will submit a focused PR with a regression that fails on the existing implementation and verifies both shallow parent discovery and complete selected-project discovery. The parent/root instructions, configured allowed roots, OAuth checks, and path containment stay unchanged. A Git marker is used as a lightweight boundary signal, not as a claim that every directory is a valid repository; unrecognized parent layouts retain current behavior.