[dVelopment]

Lets the Infisical provider authenticate as the user logged in to the Infisical CLI, and adds ?personal=true for reading and writing that user's personal overrides.

The two go together: Infisical only allows personal overrides for user identities, so they aren't reachable with a machine identity, which until now was the only way to authenticate.

CLI login

With no token and no client_id/client_secret configured (provider credentials or INFISICAL_* env), the provider runs

infisical user get token --plain --silent --domain <endpoint>

and uses that token. SECRETSPEC_INFISICAL_PATH overrides the binary; INFISICAL_PROFILE and INFISICAL_ORG are passed through the environment.

• Requires Infisical CLI 0.44.0+ (checked via infisical --version). Older CLIs ignore --domain and return the session of whatever instance you're logged in to, so a project alias pointing at another host would receive that token.
• Only one CLI run is in flight per binary/endpoint/profile/org at a time. Concurrent callers share its result, and the token is reused until it's within 60s of its exp. Failures aren't cached, so a long-running serve picks up a later infisical login.
• If stdin is a terminal, the CLI inherits it, so its browser/paste login works. Otherwise it gets no stdin and is killed (with its process group on Unix) after 30s, rather than sitting in the CLI's 10-minute login wait.
• Setting only one of client_id/client_secret is still an error and never falls through to the CLI.

Personal overrides

infisical://.../<project>?personal=true:

• Reads list with includePersonalOverrides=true, so you get your override where one exists and the shared value otherwise. Version-pinned refs still read the shared history.
• secretspec set sends type: personal. It updates your override or creates one, but never creates folders and refuses when no shared secret exists. Infisical rejects personal writes from machine identities, and the error says so.
• personal is part of the rendered URI, so a personal and a shared alias for the same project don't share cache entries.

SecretSpec before 0.22 ignores personal=true and would write the shared secret; the provider page warns about this.

Docs

providers/infisical.mdx gets "Infisical CLI login" and "Personal overrides" sections, both marked 0.22. reference/providers.mdx and the CHANGELOG are updated. The provider credentials catalog is unchanged; npm --prefix docs run check:provider-credentials passes.

Testing

Unit tests use a fake infisical binary and a local HTTP server:

• auth precedence, half-configured identities, CLI too old or unparseable, output without a token
• one CLI run shared by concurrent instances, failures retried on the next call, expired tokens fetched again
• the 30s stop without a terminal, including that the child is gone
• personal reads/writes, checking includePersonalOverrides and the type in the recorded request bodies, and the missing-environment and missing-shared-secret errors

cargo test -p secretspec provider::infisical   # 69 passed
cargo test --all

Drafted with Claude Opus 5.5 (via the omp harness), reviewed by me; the commit carries a Co-Authored-By trailer.