[BUG] bulk-export errors with "[NotSupported] Only supported for Lakehouse/Files"

[reubster]

Bug Description

When attempting to do a bulk export of items from any workspace or folder I get the error

"x bulk-export: [NotSupported] Only supported for Lakehouse/Files"

The error is actually regarding the output filepath parameter

fab bulk-export <workspace>/<folder> -o ./ --recursive

.. fails

fab bulk-export <workspace>/<folder> -o ./temp --recursive

.. succeeds.

fabric-cli version

1.7.0

Python version

Python 3.12.0

Operating System

Windows

CLI Mode

Command line mode

Authentication Method

Interactive browser login

Steps to Reproduce

1. Go to a local temporary folder.
2. Command

fab bulk-export / -o ./ --recursive

(redacted)

Expected Behavior

Users would reasonably assume the path resolution should work for any valid filesystem path

Actual Behavior

Cli immediately errors with
"x bulk-export: [NotSupported] Only supported for Lakehouse/Files"

Bulk export aborts with no items exported.

Additional Context

No response

Possible Solution

Either the path resolver needs updating to allow os-aware filepath formats, or the docs need to be more explicit about the path requirements

[microsoft-github-policy-service]

Thank you for submitting this issue, Reuben Anderson (@reubster).
A member of the Fabric CLI team will review your submission and provide feedback shortly.

[rksharma-owg]

I’d like to work on this. I reproduced the failure in the export-path resolver and bulk-export preconditions on current main (b7af89b), using Python 3.12 on macOS with a synthetic tenant context and existing local directories; no live Fabric export was run.

Both . and ./ resolve successfully to the current Fabric context, so get_export_path never reaches its local-path fallback and raises the Lakehouse/Files error. An existing ./temp directory reaches the fallback and succeeds.

Would you welcome a bulk-export-specific local-directory fix with regression tests for current-directory paths, invalid destinations, and nonempty-directory confirmation? Since bulk export already requires a local destination, I’d keep shared OneLake path precedence unchanged. If that approach fits, could this issue be marked help wanted? I’ll wait for team acknowledgment before implementation.