Summary
The CLI cannot access projects across more than one organization within a single login. If my account belongs to org A and org B, infisical login makes me pick one org, and infisical run then only works for projects in that org. Running it in a project that lives in the other org fails, even though my account has access to both.
Steps to reproduce
- Have an account that belongs to two organizations, A and B, each with at least one project.
infisical login and select org A.cd into a project whose .infisical.json points at a workspace in org B.infisical run -- printenv
Expected
Secrets for the org-B project are fetched, since my account has access to org B.
Actual
The request is rejected (not authorized / project not found). The only workaround is to infisical login again and select org B, which then breaks projects in org A. There is no way to work across both orgs without re-logging in each time you switch.
The existing login-time org flags (--organization-id in #43, --organization-slug in #143) pick the org at login and so don't cover this: the problem is running against a second org within a session, not choosing which single org to log into.
Proposed solution
The re-scoping mechanism already exists: infisical init lets a logged-in user pick a different organization mid-session and calls POST /v3/auth/select-organization to mint a token scoped to the chosen org, without re-entering credentials. The same call can be reused in the secrets-fetch path:
- Record the selected
organizationId in .infisical.json at infisical init time (optional field, backward compatible).
- Add an
--organization-id flag to infisical run, plus an INFISICAL_ORGANIZATION_ID env var.
- When a target org is resolved (flag, then env, then
.infisical.json) and it differs from the current token's org, mint a token for that org via select-organization and use it for that invocation only. When no target org is set, behavior is unchanged.
This keeps single-org usage identical and lets a multi-org user run against any org they already have access to without re-logging in. I have an implementation ready in a PR.
Summary
The CLI cannot access projects across more than one organization within a single login. If my account belongs to org A and org B,
infisical loginmakes me pick one org, andinfisical runthen only works for projects in that org. Running it in a project that lives in the other org fails, even though my account has access to both.Steps to reproduce
infisical loginand select org A.cdinto a project whose.infisical.jsonpoints at a workspace in org B.infisical run -- printenvExpected
Secrets for the org-B project are fetched, since my account has access to org B.
Actual
The request is rejected (not authorized / project not found). The only workaround is to
infisical loginagain and select org B, which then breaks projects in org A. There is no way to work across both orgs without re-logging in each time you switch.The existing login-time org flags (
--organization-idin #43,--organization-slugin #143) pick the org at login and so don't cover this: the problem is running against a second org within a session, not choosing which single org to log into.Proposed solution
The re-scoping mechanism already exists:
infisical initlets a logged-in user pick a different organization mid-session and callsPOST /v3/auth/select-organizationto mint a token scoped to the chosen org, without re-entering credentials. The same call can be reused in the secrets-fetch path:organizationIdin.infisical.jsonatinfisical inittime (optional field, backward compatible).--organization-idflag toinfisical run, plus anINFISICAL_ORGANIZATION_IDenv var..infisical.json) and it differs from the current token's org, mint a token for that org viaselect-organizationand use it for that invocation only. When no target org is set, behavior is unchanged.This keeps single-org usage identical and lets a multi-org user run against any org they already have access to without re-logging in. I have an implementation ready in a PR.