Skip to main content
The CLI’s target context determines which organization and project your commands operate on. You must authenticate before setting target context.

​
Flags

--org and --organization-id are mutually exclusive — use one or the other. The same applies to --project and --project-id.

​
How operations use target context

​
Target context by auth method

​
User login

After pc auth login, the CLI auto-targets your default organization and its first project.

​
Service account

Via CLI command: After pc auth configure --client-id --client-secret, the CLI auto-targets the service account’s organization. For the project:
  • If one project exists, it’s auto-targeted
  • If multiple exist, you’re prompted (or use --project-id)
  • If none exist, create one and target it manually
Via environment variables: If using PINECONE_CLIENT_ID and PINECONE_CLIENT_SECRET without running pc auth configure, no target context is set automatically. Run pc target to set it.

​
API key

When using an API key, control plane and data plane operations use the key’s org/project scope, not the CLI’s stored target context. The pc target --show output does not reflect what these operations actually use.
API keys are scoped to a specific org and project and cannot access resources outside that scope. Admin API operations still use your user login or service account credentials (API keys can’t authenticate Admin API calls).

​
Managing target context

​
JSON mode and non-TTY environments

Running pc target --json with no targeting flags returns the current target context as a JSON object. This is a local-state read — no authentication is required:
In non-TTY environments (CI/CD pipelines, shell pipes, scripts), JSON output is automatic — the same as passing --json explicitly. You do not need to add the flag in automation contexts. Use --organization-id and --project-id (instead of name flags) to set context reliably in scripts, since IDs are stable and unaffected by renames: