1Password CLI Bug Report: Service Account Cannot Read Environments

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.

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.

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