---
title: "MGS1023: workspace provider reported an unusable project path"
description: Fires when a workspace provider's list_projects returns a path magus cannot accept as a project - empty, absolute, escaping the workspace root, the root itself, or not an existing directory.
tags: [MGS1023, magusfile, workspace-providers, projects, spells]
---

# MGS1023: workspace provider reported an unusable project path

A spell wired with `magus\workspace.provider(...)` returned a project whose
`path` magus cannot turn into a project. The message names the provider, the
path it reported, and which rule the path broke:

```text
[MGS1023] workspace provider "nx" reported project path "/abs/libs/foo":
project paths are relative to the workspace root, never absolute
```

The rules a reported path must satisfy:

| Rule                      | Why                                                                                          |
| ------------------------- | -------------------------------------------------------------------------------------------- |
| non-empty                 | a project is addressed by its path; there is nothing to address                              |
| relative, not absolute    | every project path in magus is repo-relative, so target identity is portable across machines |
| inside the workspace root | magus never operates outside the workspace it discovered                                     |
| not `.`                   | the root project belongs to the magusfile that wired the provider                            |
| an existing directory     | a project's directory is what the cache key hashes and what its targets run in               |

## Why this fails the load

A provider is code that shelled out to another tool, which makes its answer the
least trustworthy input in the load path. magus rejects it rather than repairing
it, and fails rather than skipping the entry: a dropped project is a target that
no longer exists, and `magus run test` would report success having run nothing.

## Resolution

Fix the provider's `list_projects` so every `Project` it returns carries a
workspace-relative path to a real directory. Reporting the foreign tool's project
root verbatim is usually right - `nx show project <p> --json` gives `root` in
exactly this form:

```buzz
export fun list_projects(target: Target, cb: fun(any)) > [Project] {
    // root comes from the tool already repo-relative: "libs/foo", not "/abs/libs/foo"
    return [Project{ path = "libs/foo", spells = ["nx"] }];
}
```

If the tool reports absolute paths, make them relative to the workspace root
before returning them. The root is handed to the contract through `cb`:

```buzz
final io = {<str: any>};
cb(io);
final root = io["root"] ?? "";
```

## See also

- [Workspace providers](../../../concepts/workspace/providers.md)
- [MGS1024](MGS1024.md): the provider reported a path that already has a magusfile