1Password CLI Bug Report: Service Account Cannot Read Environments

Any debug command flags we can add to help debug this? Also getting the same error with the same setup.

More info after some reverse engineering of the binary:

Here's the complete API call sequence for op environment read with a service account:

1. POST /api/v3/auth/start (200 OK) -- initiates SRP auth
   {"email":"YYYYYYYYYYYYYYY@1passwordserviceaccounts.com","skFormat":"A3","skid":"ZZZZZZZZZZ","deviceUuid":"BBBBBBBBBBBBBBBBBBBBBBBB","userUuid":""}
2. POST /api/v1/auth (200 OK) -- completes SRP handshake (sends userA, sessionID)
3. POST /api/v2/auth/verify (200 OK) -- verifies auth, gets session token
4. GET /api/v2/account/keysets (200 OK) -- fetches account keysets (x2)
5. GET /api/v2/overview (200 OK) -- fetches account overview
6. GET /api/v3/vault/XXXXXXXXXXXXXXXXXXX?attrs=combined-access -- 403 Forbidden!

There's the problem. The CLI treats the environment ID (XXXXXXXXXXXXXXXXXXX) as a vault ID and tries to fetch it via /api/v3/vault/{id}. The server returns 403 because:

- The service account doesn't have access to that "vault" (it's not actually a vault -- it's an environment), or
- The Environments feature uses a different API path that the CLI isn't calling when authenticated as a service account
- The response body (gzip-decoded \xaa\xae\xe5 = {} with a newline) is essentially an empty error body, and the CLI maps it to the generic "An unexpected error occurred while processing the request."

Bottom line: op environment read with a service account authenticates fine but then tries to access the environment as if it were a vault via /api/v3/vault/{environmentId}?attrs=combined-access, and gets a 403. This strongly suggests that Environments aren't supported for service accounts at the API level -- the service account lacks the permissions/role to access the environment vault, or the environment is stored in a way that isn't exposed to service accounts.

Ooo! I fixed it! The service account did not have permissions to access the environment. I had to create a new one and while creating it adding the correct environments as read-access.

Key insight from LLM:

Environments ARE vaults under the hood. The SDK's EnvironmentsGetVariables implementation first calls GET /api/v3/vault/{environment_id}?attrs=combined-access to access the environment's backing vault. The environment ID you pass (XXXXXXXXXXX) IS the vault ID of that environment.

The 403 is a permissions issue. Your service account only has access to one vault:

{ "id": "XXXXXXXXXXXXXx", "name": "Infrastructure", "items": 1 }

The environment vault XXXXXXXX is not in that list. The service account hasn't been granted access to it.