SharePoint connector: list_folder_items returns Graph 400 "Resource not found for the segment 'root:'" for a valid folder

What version of Codex is running?

ChatGPT desktop app for macOS, version 26.901.20858 (released Sep 2, 2026), "Powered by Codex & OWL". The SharePoint connector was used from within the app.

What subscription do you have?

ChatGPT Enterprise

Which model were you using?

5.6-sol, extra high reasoning

What platform is your computer?

macOS

Component

Microsoft SharePoint app connector (codex_apps / microsoft_sharepoint.list_folder_items)

What issue are you seeing?

microsoft_sharepoint.list_folder_items returns a Microsoft Graph 400 Resource not found for the segment 'root:' for a folder that exists, when called with arguments that match the documented contract (drive-root-relative folder_path, no library prefix). search and fetch on the same connector work fine; only folder listing fails. A colleague reproduced the identical error independently.

Tenant, site, and folder names below are anonymized; the real values follow the same shape (a team site whose default document library is Shared Documents, and a three-level folder path containing spaces).

Raw tool call:

{
  "server": "codex_apps",
  "tool": "microsoft_sharepoint.list_folder_items",
  "arguments": {
    "hostname": "contoso.sharepoint.com",
    "site_path": "/sites/ExampleTeamSite",
    "folder_path": "Team Share/Subfolder/Folder Name",
    "top": 1000
  }
}

Result:

HTTPError: 400: Resource not found for the segment 'root:'.
(Response: {"error":{"code":"BadRequest","message":"Resource not found for the segment 'root:'.",
"innerError":{"date":"2026-09-03T09:34:40",
"request-id":"7bc65302-485f-4505-b93a-af9030e71e8c",
"client-request-id":"7bc65302-485f-4505-b93a-af9030e71e8c"}}})
error_code: INVALID_ARGUMENT

The folder is a normal folder inside the site's default document library. Browser URL (anonymized):

https://contoso.sharepoint.com/sites/ExampleTeamSite/Shared%20Documents/Forms/AllItems.aspx?id=%2Fsites%2FExampleTeamSite%2FShared%20Documents%2FTeam%20Share%2FSubfolder%2FFolder%20Name

Verification that the resource exists and Graph can list it

Same user, delegated Graph permissions, via a separate client (Azure CLI Graph token), names anonymized as above:

GET /sites/contoso.sharepoint.com:/sites/ExampleTeamSite
→ 200. id = contoso.sharepoint.com,<guid>,<guid>

GET /sites/contoso.sharepoint.com:/sites/ExampleTeamSite:/drives
→ 200. Default drive: b!<drive-id>  "Documents"  .../sites/ExampleTeamSite/Shared%20Documents
   (the only other drive returned is a system list, "Search Config List")

GET /drives/b!<drive-id>/root:/Team%20Share/Subfolder/Folder%20Name:/children
→ 200, returns the folder's children.

GET /sites/contoso.sharepoint.com,<guid>,<guid>/drive/root:/Team%20Share/Subfolder/Folder%20Name:/children
→ 200, same children.

So the drive is unambiguous and the folder_path Codex was given is correct.

Reproducing the exact error outside Codex

The same folder path, with the site addressed by hostname + server-relative path instead of by ID, produces the error Codex surfaced, byte for byte:

GET /sites/contoso.sharepoint.com:/sites/ExampleTeamSite:/drive/root:/Team%20Share/Subfolder/Folder%20Name:/children
→ 400 BadRequest: Resource not found for the segment 'root:'.   request-id c64aeb94-286d-4d98-bd2f-c43a3895ea5d

GET /sites/contoso.sharepoint.com:/sites/ExampleTeamSite/drive/root:/Team%20Share/Subfolder/Folder%20Name:/children
→ 400 BadRequest: Resource not found for the segment 'root:'.   request-id 97d24bc7-9510-4900-ba17-d01cca0d9fa2
   (same, without the closing colon after the site path)

For comparison, other mistakes produce different errors, so those can be ruled out:

GET /sites/contoso.sharepoint.com,<guid>,<guid>/root:/Team%20Share/…:/children        (site ID, no /drive)
→ 400 BadRequest: Resource not found for the segment 'getByPath'.

GET /drives/b!<drive-id>/root:/Shared%20Documents/Team%20Share/…:/children             (library prefix in path)
→ 404 itemNotFound

Why this looks like a connector bug

Graph returns Resource not found for the segment 'root:' whenever the site is addressed with the /sites/{hostname}:{site_path} form and a root:/{path}: segment is appended in the same URL. Graph accepts that identical folder path when the site or drive is addressed by ID. The tool's hostname and site_path arguments map directly onto the /sites/{hostname}:{site_path} form, so the likely cause is that list_folder_items appends /drive/root:/{folder_path}:/children to it instead of first resolving the site (or its default drive) to an ID. That also explains why search and fetch work: neither builds a path-addressed URL this way.

Suggested fix: GET /sites/{hostname}:{site_path} to get the site ID, then GET /sites/{site-id}/drive/root:/{folder_path}:/children (or /drives/{drive-id}/root:/{folder_path}:/children), which are the forms the driveItem list-children docs list.

What steps can reproduce the bug?

1. Connect the Microsoft SharePoint app in Codex.
2. Ask Codex to list the contents of a folder on a SharePoint team site, e.g. "list the files in Team Share/Subfolder/Folder Name on the ExampleTeamSite site".
3. Codex calls microsoft_sharepoint.list_folder_items with the arguments above.
4. The call fails with the 400 above.

What is the expected behavior?

list_folder_items returns the folder's children, matching what GET /drives/{driveId}/root:/{folder_path}:/children returns for the same user.

Additional information

• Graph request-id for the failing Codex call: 7bc65302-485f-4505-b93a-af9030e71e8c (2026-09-03T09:34:40Z). Request IDs for the out-of-band reproductions are inline above. Happy to share the real tenant/site/path privately if that helps trace it.
• search(query=...) and fetch on the same connector succeed against the same site, so auth and permissions are not the issue.

Start by locating the implementation of microsoft_sharepoint.list_folder_items and compare its URL construction with the documented Microsoft Graph drive-item endpoints described in the issue. Verify the hostname/site-path request and the site-ID or drive-ID alternatives, then confirm that listing the reported folder returns its children without the root: error.