1Password CLI Bug Report: Service Account Cannot Read Environments

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.