gws drive +upload doesn't work with Shared Drive folders

[Dan-Wilhelm]

Hello together,
something I've stumbled upon while using the workspace cli:

What's wrong

Trying to upload into a Shared Drive folder fails with 404 File not found,
because +upload doesn't pass supportsAllDrives: true to the Drive API.
There's also no way to add it manually — the helper rejects --params.

So the helper is effectively unusable for anyone whose Drive content lives
on a Shared Drive (which is most teams).

This is related to #327 (which is about telling agents to add the flag when
calling the raw API), but separate: that issue is about awareness, this one
is about the helper having no way to set the flag at all.

How to reproduce

CLI version: @googleworkspace/cli v0.22.5

echo "test" > /tmp/test.txt
gws drive +upload /tmp/test.txt --parent <SHARED_DRIVE_FOLDER_ID>

Result:

{
  "error": {
    "code": 404,
    "message": "File not found: <SHARED_DRIVE_FOLDER_ID>.",
    "reason": "notFound"
  }
}

Trying to add the flag manually:

gws drive +upload /tmp/test.txt --parent <FOLDER_ID> \
  --params '{"supportsAllDrives": true}'

also fails:

error[validation]: error: unexpected argument '--params' found

What works

Skip the helper, use the raw API:

gws drive files create \
  --params '{"supportsAllDrives": true}' \
  --json '{"name": "test.txt", "parents": ["<FOLDER_ID>"]}' \
  --upload /tmp/test.txt

Suggested fixes (any one would resolve)

1. Set supportsAllDrives: true by default in +upload. The flag is
   safe for non-shared drives — it has no effect when the parent isn't on
   a Shared Drive — so passing it unconditionally costs nothing and fixes
   the helper.
2. Add a --shared-drive boolean flag that opts in.
3. Allow --params as an escape hatch on +upload (and other helpers,
   for consistency with the raw API surface).

Option 1 is least friction for users (they don't need to know Shared Drives
are a thing); option 3 is most consistent with the rest of the CLI.

Environment

• OS: Windows 10 (Git Bash)
• gws CLI: 0.22.5

---

Cheers
Dan

[gubonlucid-com]

echo "test" > /tmp/test.txt
gws drive +upload /tmp/test.txt --parent <SHARED_DRIVE_FOLDER_ID>gws drive +upload /tmp/test.txt --parent <FOLDER_ID>
--params '{"supportsAllDrives": true}'{
"error": {
"code": 404,
"message": "File not found: <SHARED_DRIVE_FOLDER_ID>.",
"reason": "notFound"
}
}error[validation]: error: unexpected argument '--params' foundgws drive files create
--params '{"supportsAllDrives": true}'
--json '{"name": "test.txt", "parents": ["<FOLDER_ID>"]}'
--upload /tmp/test.txt

[hoyt-harness]

Adding a reproduction case from a Windows environment and a note on the cascading issue this causes.

---

Environment tested: Windows 10/11, gws v0.22.5 x86_64, cmd /c invocation, Business shared drive.

Reproduction

Attempt with shared-drive flags — fails at flag validation:

gws drive +upload test.txt --name "test.txt" --parent <shared-drive-folder-id> --drive-id <shared-drive-id> --supports-all-drives

Exit code 3:

error[validation]: error: unexpected argument '--drive-id' found

  tip: to pass '--drive-id' as a value, use '-- --drive-id'

Usage: gws +upload --name <n> --parent <ID> <file>

Attempt without shared-drive flags — fails at the API level:

gws drive +upload test.txt --name "test.txt" --parent <shared-drive-folder-id>

Without supportsAllDrives=true, the API returns a 404 because the shared drive folder ID is not recognized in the My Drive namespace.

Working path — raw drive files create --upload:

gws drive files create --params "{\"supportsAllDrives\":true}" --json "{\"name\":\"test.txt\",\"parents\":[\"<shared-drive-folder-id>\"]}" --upload test.txt

This works and returns the expected Drive file resource with driveId and teamDriveId populated.

---

Cascading issue with --upload path restriction

The workaround above is further complicated by a separate bug: --upload (and --output) reject absolute file paths, requiring the source file to be in gws's current working directory. So the full workaround sequence for uploading any file to a shared drive is:

1. Copy the source file into gws's cwd
2. Run drive files create with the relative filename and explicit supportsAllDrives
3. Clean up the copy

This is significant friction for any automation pipeline where the source file is in a fixed or generated location.

---

Suggested minimum-viable fix

Inject supportsAllDrives=true unconditionally when --parent is present in +upload. Passing it for My Drive parents is harmless (the Drive API accepts it silently), and it's required for any shared drive parent. This mirrors the pattern used in Google's own client libraries.

A --supports-all-drives explicit flag (or --shared-drive) would also be acceptable and more predictable for users who want explicit control.