[Bug]:OneDrive (personal) auth gets stuck indefinitely on "Connecting to OneDrive" + workaround

What happened?

What happened?

OneDrive (personal) auth gets stuck indefinitely on "Connecting to OneDrive... Please DO NOT close this modal." A subsequent "Check Connectivity" fails with a generic Error: Request failed, status 400.

Root cause: the plugin's folder-creation request uses @microsoft.graph.conflictBehavior: "replace" when creating the vault's subfolder inside the OneDrive app folder. Per Microsoft's own Graph API documentation, replace is only supported for files, not folders — folders should use fail or rename. This causes OneDrive to reject the request with a generic 400, which the plugin doesn't surface to the user, so the UI just hangs.

This happens on any first-time connection where the vault-named subfolder doesn't already exist under /Apps/remotely-save/ — i.e. any new vault, or any vault where the folder was deleted and needs recreating.

Steps to reproduce Connect a vault to OneDrive (personal) via Remotely Save, where /Apps/remotely-save// does not yet exist Auth completes successfully (token exchange succeeds) Plugin GETs /v1.0/drive/special/approot/children → 200 OK, confirms folder is empty Plugin POSTs to /v1.0/drive/special/approot/children to create the vault subfolder → 400 Bad Request Modal hangs on "Connecting to OneDrive" forever; no error is surfaced to the user Restarting Obsidian and clicking "Check Connectivity" reproduces the same 400 Request that fails

POST https://graph.microsoft.com/v1.0/drive/special/approot/children
Content-Type: application/json
Authorization: Bearer <redacted>

{
    "@microsoft.graph.conflictBehavior": "replace",
    "folder": {},
    "name": "REJ"
}

Response

HTTP/1.1 400 Bad Request
Content-Type: application/json

{
    "error": {
        "code": "invalidRequest",
        "message": "Invalid request",
        "innerError": {
            "client-request-id": "<redacted>",
            "date": "2026-08-13T16:08:07",
            "request-id": "<redacted>"
        }
    }
}

Reference

Microsoft's own docs on driveItem: copy state: "The replace value is only supported for files; folders with conflicts use the fail behavior instead." (https://learn.microsoft.com/en-us/graph/api/driveitem-copy?view=graph-rest-1.0) — the same restriction appears to apply to folder creation via POST /children.

Workaround

Manually create the vault-named subfolder yourself inside /Apps/remotely-save/ on onedrive.live.com before running Check Connectivity. Since the plugin only attempts the (broken) creation call when the folder is missing, pre-creating it lets the plugin skip straight past the bug.

Environment OS: Ubuntu (Linux), Obsidian installed via Flatpak (md.obsidian.Obsidian) Obsidian version: 1.13.7 Remote service: OneDrive for personal (App Folder / free tier) Confirmed via mitmdump HTTPS interception of the plugin's actual Graph API traffic How this was diagnosed

Traced the entire OAuth + Graph API flow via mitmdump (proxying Obsidian's Flatpak process with http_proxy/https_proxy env vars and NODE_EXTRA_CA_CERTS), since Obsidian plugins call Microsoft's APIs via Electron's main process, which is invisible to the renderer's own DevTools Network tab. This confirmed:

Token exchange (auth code → access token): succeeds (200) Token refresh: succeeds (200) GET approot/children: succeeds (200, empty array) POST approot/children (folder creation): fails (400) — this is the actual break point

What OS are you using?

Linux

What remote cloud services are you using? (Please choose the specified one if it's in the list)

OneDrive for personal

Version of the plugin

0.5.25

Version of Obsidian

1.13.7

Using password or not

• Yes.

Ensure no sensitive information

• I ensure that no sensitive information is submitted in the issue.