Why can I sign in but still get a Cloud access error?

Signing in identifies you. Cloud also checks the Account and Project used by the request, the Project's enabled services, and the permissions granted to your identity. An access error can come from any of these checks, so keep the exact error text while you identify the failing step.

Check the Account and Project

Confirm that the CLI is signed in to the Account that owns the Project. A browser session and a terminal session can use different Accounts; success in one does not establish access in the other.

With the Project plugin installed, retrieve the known Project. Replace PROJECT_ID with its proj_… ID:

socra project get PROJECT_ID

If you are finding a Project through socra project list, continue through every page. The default page contains up to 20 rows, and an omitted Project may be on a later page. Use the printed --after cursor before treating the omission as an authorization problem.

Check service enablement

With the Service plugin installed, inspect the Project's enabled services:

socra service list --enabled --project PROJECT_ID

An error containing SERVICE_DISABLED identifies a service-enablement check. Enable the required service on that Project if you have permission, or ask its administrator to do so. This step does not grant the permissions required for the service's resource operations.

Inspect the relevant permissions

IAM groups permissions into roles and binds those roles to identities. If your identity can read the Project policy, use the IAM plugin:

socra iam policy get --project PROJECT_ID

You can also inspect the roles and permissions published by the failing service. Replace SERVICE_NAME with its exact name, such as run.socra.cloud:

socra iam role list --service SERVICE_NAME
socra iam permission list --service SERVICE_NAME

Ask the Project administrator for the role needed by the specific operation. Include the Project ID, service, exact error, and the identity that made the request. Access policies can include conditions, deny rules, and inherited Account policies, so a role name alone does not explain every decision.

Reading the policy also requires access. If that command is denied, give the administrator its error along with the original failure. Account-level inherited policy administration requires Account-owner authority.

Keep passwords, bearer tokens, and private keys out of an access request. The IAM reference explains the policy and identity surfaces.