feat(export): support multiple --path flags to merge secrets from several paths

[codewithsupra]

Problem

infisical export only accepted a single --path flag, making it impossible to merge secrets from several folder paths in one command.
The infisical run command already supported this via StringArray (issue #900 tracked the gap across the CLI).

Solution

Switch export's --path flag from String to StringArray so users can pass it multiple times:

# merge /global + /app-a secrets into one .env
infisical export --path /global --path /app-a --env prod > .env

# default (single path) still works unchanged
infisical export --path /backend --env prod --format json

What changed (packages/cmd/export.go)

Before	After
Flags().String("path", "/", …)	Flags().StringArray("path", []string{"/"}, …)
GetString("path") → single SecretsPath	GetStringArray("path") → SecretsPaths []string
models.GetAllSecretsParameters + manual override	models.GetMultiPathSecretsParameters passed to fetchSecrets()

fetchSecrets() is already defined in run.go (same cmd package) and handles per-path fetching, token injection, dedup, and personal/shared override — this PR reuses it without duplication.

Backwards compatibility

• Single --path /foo still works exactly as before.
• Default behaviour (--path /) is unchanged.
• No changes to any other command.

Testing

# Single path (regression)
infisical export --path / --env dev

# Multiple paths
infisical export --path /global --path /service-a --env staging --format dotenv

Closes #900 (export command)

---

🤖 Generated with Claude Code

[greptile-apps]

Greptile Summary

This PR aligns the export command with the existing run command by switching the --path flag from String to StringArray, allowing users to merge secrets from multiple folder paths in a single infisical export invocation. It avoids duplication by delegating directly to the existing fetchSecrets() helper in run.go.

• The flag type change is minimal and backwards-compatible; single-path and default (/) usage are unaffected.
• The removal of the inline token-injection block is correct — that logic is now handled per-path inside fetchSecrets().
• When two or more paths contain a secret with the same key, fetchSecrets appends all copies and OverrideSecrets only resolves personal-vs-shared conflicts, not cross-path conflicts. The run path avoids this via getSecretsByKeys's map deduplication, but the export path has no equivalent, so duplicate keys can appear in the exported file.

Confidence Score: 4/5

Safe to merge for the common single-path case; multi-path usage may produce duplicate keys in exported output when two paths share a secret name

The change is a small, focused delegation to an already-tested helper. The duplicate-key edge case in multi-path export is real but only manifests when paths deliberately overlap on key names, and the symptom (last-value-wins or repeated key) is tolerable in most formats.

packages/cmd/export.go — specifically the post-fetch pipeline where cross-path duplicate keys are not deduplicated before formatting

Important Files Changed

Filename	Overview
packages/cmd/export.go	Switches --path from String to StringArray and delegates to fetchSecrets() from run.go; works correctly for the single-path case, but multi-path usage can produce duplicate keys in the exported output when two paths share a secret name

_{Reviews (1): Last reviewed commit: "feat(export): support multiple --path fl..." | Re-trigger Greptile}

[greptile-apps]

Duplicate keys in multi-path export output

When two or more paths contain a secret with the same key, fetchSecrets appends all of them into allSecrets and then calls OverrideSecrets, which only resolves personal-vs-shared conflicts — not cross-path conflicts. The result is that the final slice can hold multiple entries for the same key, producing duplicate keys in the exported output (e.g. the same DB_HOST appearing twice in a .env file). In run.go this is silently deduplicated downstream by getSecretsByKeys, which uses a map; the export path has no equivalent step. A consumer that relies on only one value per key (dotenv, yaml) will silently use whichever instance appears last, which may not be the intended one.