# Language-agnostic project and workspace root detection

**URL:** <https://community.osaurus.ai/t/language-agnostic-project-and-workspace-root-detection/37>\
**Category:** Feature Requests\
**Tags:** windows\
**Created:** [October 6, 2026, 4:07am UTC](https://community.osaurus.ai/t/language-agnostic-project-and-workspace-root-detection/37 "2026-10-06T04:07:52Z")\
**Posts on this page:** 5\
**Page:** 1

<div class="post-metadata">

**Author:** ![junn\_4.8](https://sea1.discourse-cdn.com/flex045/user_avatar/community.osaurus.ai/junn_4.8/32/14_2.png) [@junn\_4.8](https://community.osaurus.ai/u/junn_4.8)\
**Post date:** [October 6, 2026, 4:07am UTC](https://community.osaurus.ai/t/language-agnostic-project-and-workspace-root-detection/37/1 "2026-10-06T04:07:52Z")

</div>

For coding tasks, it would be useful if Osaurus could distinguish between:

`repository root -> workspace -> project/module -> project manifest`

rather than treating every selected directory or project file as equivalent context.

Ideally this would be language and build-system agnostic, with common examples such as:

`.sln / .slnx / .csproj`  
Maven / Gradle  
`package.json` workspaces  
`Cargo.toml`  
`go.mod`  
`pyproject.toml`  
`CMakeLists.txt`

Monorepos are another important case, since one repository may contain several projects.

I’m not asking for a full IDE project system — mainly reliable context/root detection so the agent starts work at the correct scope.

---

<div class="post-metadata">

**Author:** ![sonofnun](https://avatars.discourse-cdn.com/v4/letter/s/4bbf92/32.png) [@sonofnun](https://community.osaurus.ai/u/sonofnun)\
**Post date:** [October 15, 2026, 12:27am UTC](https://community.osaurus.ai/t/language-agnostic-project-and-workspace-root-detection/37/2 "2026-10-15T00:27:59Z")

</div>

How do you see this changing behavior in Osaurus?

---

<div class="post-metadata">

**Author:** ![junn\_4.8](https://sea1.discourse-cdn.com/flex045/user_avatar/community.osaurus.ai/junn_4.8/32/14_2.png) [@junn\_4.8](https://community.osaurus.ai/u/junn_4.8)\
**Post date:** [October 15, 2026, 9:51am UTC](https://community.osaurus.ai/t/language-agnostic-project-and-workspace-root-detection/37/3 "2026-10-15T09:51:16Z")

</div>

The main change I’m looking for is how Osaurus establishes the task scope before reading files, editing code, or running build/test commands.  
For example, my .NET repository contains several projects, shared documentation, and repository-level instructions. If I select a project subfolder, I would like Osaurus to identify the containing solution/repository and distinguish:

- The selected folder and granted access scope.
- The repository/solution root.
- The specific project or module being worked on.
- The appropriate working directory and build/test entry points.

In practice, this could help the agent find applicable repository instructions, understand project references, and avoid running commands from the wrong directory or assuming that one project folder represents the entire repository.

For a monorepo, it should identify the relevant package/module without automatically treating every sibling project as part of the task.

I’d also like the detected scope to be visible and overridable. If detection is ambiguous, Osaurus could ask which project to target. Detecting a parent root should not silently expand filesystem permissions; additional access should still require approval.

An initial implementation could simply provide a “Detected project context” summary to the agent and user, with suggested working directories and build/test entry points. A full IDE project system would not be necessary.

I haven’t established that my recent coding run failed because of root detection; this request is about making scope selection more predictable and visible.

---

<div class="post-metadata">

**Author:** ![sonofnun](https://avatars.discourse-cdn.com/v4/letter/s/4bbf92/32.png) [@sonofnun](https://community.osaurus.ai/u/sonofnun)\
**Post date:** [October 15, 2026, 10:33am UTC](https://community.osaurus.ai/t/language-agnostic-project-and-workspace-root-detection/37/4 "2026-10-15T10:33:33Z")

</div>

Thanks, I think I understand. So the ask is: when you attach a folder, Osaurus works out the enclosing repo/solution root and the specific project, shows you that as a “Detected project context” (with suggested build/test commands), lets you correct it, and never widens file access because of what it found. Is picking up repo-level instruction files (like an `AGENTS.md` at the root) the main payoff for you, or is it mostly about commands running from the right directory?

---

<div class="post-metadata">

**Author:** ![junn\_4.8](https://sea1.discourse-cdn.com/flex045/user_avatar/community.osaurus.ai/junn_4.8/32/14_2.png) [@junn\_4.8](https://community.osaurus.ai/u/junn_4.8)\
**Post date:** [October 15, 2026, 1:29pm UTC](https://community.osaurus.ai/t/language-agnostic-project-and-workspace-root-detection/37/5 "2026-10-15T13:29:03Z")

</div>

> [@junn\_4.8](#):
>
> For coding tasks, it would be useful if Osaurus could distinguish between:

Yes, that captures it well. For my workflow, both are important—the main payoff is giving the agent reliable project scope.

My repository contains several components, including C#/.NET projects, a WinUI app, and Python tooling. If I attach a subfolder, I’d like Osaurus to distinguish:

- The repository root, where shared instructions and architecture documentation live.
- The solution/workspace and the specific project I’m working on.
- The working directory and build/test commands appropriate to that task.

Picking up applicable instructions such as `AGENTS.md` is important, including any more specific instructions in subdirectories. Running commands from the correct directory is equally important, so the agent doesn’t accidentally build or test an unrelated project—or the whole repository.

I agree that detection should never silently widen file access. If relevant instructions or project files are outside the attached folder, Osaurus could explain what it found and let me explicitly attach or grant access to the parent folder.

A visible, editable “Detected project context” would be a useful first version. Suggested commands should be presented as suggestions, with their working directories, rather than automatically executed.
