Google Workspace CLI: authenticate gws and verify one Drive query
gws exposes Google Workspace APIs as CLI commands and includes agent skills. Start with one account, one service and a read-only Drive query. The repository is in the googleworkspace organization, but explicitly says it is not an officially supported Google product.
Start with prerequisites ↓01 · Project
Configure the API and OAuth application.
02 · Account
Authorize only the scopes needed for the task.
03 · Query
Inspect the command, then verify its returned records.
Installing a skill is not authentication. A successful login does not prove that the account can access a particular file.
1. Install the CLI and inspect its interface
Use the repository's release or installation instructions. The npm route needs Node.js 18 or later:
npm install -g @googleworkspace/cli
gws --help
gws drive files list --help
gws schema drive.files.list
The CLI builds its interface from Google Discovery documents. Inspect the schema for the installed version rather than assuming a copied command remains valid forever. The project is actively developed before 1.0 and warns about breaking changes. Record the installed version when you save a working procedure.
2. Choose an OAuth route deliberately
The documented gws auth setup route uses gcloud to help configure a project and APIs. It can change Google Cloud configuration; it is not just a local check. If you already have an approved project, follow the manual OAuth Desktop-client path in the authentication guide instead.
For a manual setup, configure the OAuth app and test user where applicable, download the Desktop client's JSON to the documented configuration location, then start with the Drive service:
gws auth login -s drive
Inspect the requested scopes before consenting and select the minimum read access suitable for your task. The service selector is not itself a guarantee of read-only access. An organization administrator may restrict consent. Do not grant every service simply because a narrower setup fails.
3. Preview and run a small Drive listing
In a POSIX shell, first inspect the request with dry-run, then issue it once:
gws drive files list --params '{"pageSize":5,"fields":"files(id,name),nextPageToken"}' --dry-run
gws drive files list --params '{"pageSize":5,"fields":"files(id,name),nextPageToken"}'
Dry-run is request inspection, not evidence that OAuth, API access or the query will succeed. The examples and flags follow the CLI documentation. Windows shell quoting differs; use a supported shell and check the rendered parameters before an actual call.
Compare a returned file ID and name with the intended account's Drive. Five results are only a page, not a full inventory; a next-page token means more may exist. Do not interpret an empty page as proof that the account has no files.
4. Add only the skill dependencies you need
The repository includes a Drive skill that refers to the shared gws instructions. If you copy that skill, include and review its shared dependency too. Copying a single SKILL.md without its referenced files can leave an agent with incomplete instructions.
For an initial agent task, ask it to explain the already-returned JSON and identify the account or permission assumptions. If you then allow a live query, specify one read-only call, the expected fields and no sharing or write operations. Inspect both the proposed command and the result. A natural-language instruction is not an OAuth restriction.
5. Fix the failed layer
For a denied request, separate API enablement, OAuth scope, organization policy and access to the particular resource. Check the structured error before changing permissions. For throttling, respect the API's retry guidance and avoid immediate repeated calls. An invalid parameter should send you back to gws schema, not to broader authorization.
Keep credentials and downloaded OAuth files out of repositories and chat. Follow the project's storage and authentication documentation for the machine you use. A local command transcript should contain the result you need, not a raw token dump.
6. Costs, support and a useful next step
gws is Apache-2.0-licensed and explicitly not an officially supported Google product. That is separate from the support, subscription requirements and quotas of the underlying Google services. Google Workspace, Cloud resources and an agent's model usage can each have their own terms or costs. Repository notice and license
Stop the first trial after one verified read. A next step might be a report over a chosen folder, with pagination and a known expected count. Do not jump directly to bulk edits, Gmail sends or sharing changes. For a reusable procedure, package only the verified steps using the SKILL.md guide.
FAQ
Is gws an officially supported Google product?
The repository explicitly says it is not. Its organization name should not be treated as a support or availability guarantee.
Does gws auth login -s drive mean read-only?
No. Inspect the actual scopes requested and approved. Selecting a service and limiting its permissions are different decisions.
Did you authorize or query a real account?
No. Commands were checked against source documentation; account authorization and API behavior were not tested.
Primary sources
Source-checked 2026-10-25. Published documentation, account availability and a hands-on workflow are separate evidence. Examples and checklists here are editorial material.