Infiscal with cross-project secrets #5413

Activity

1. nabeelio

   added

   needs-triage🔍

   on Sep 10, 2026
2. linear-code commented on Sep 10, 2026

   

   linear-codeBot

   on Sep 10, 2026 – with Linear Code

   More actions

   DOK-764
3. aspatari commented on Sep 10, 2026

   

   aspatari

   on Sep 10, 2026

   More actions

   @nabeelio picked this up — PR #5414.

   What was actually happening

   Two things, and the first explains why it looked like the secret didn't exist rather than like a permissions or path problem.

   The list endpoint takes the flag in snake_case. includeImports is silently ignored: the request still returns 200, with imports present but empty. Measured against app.infisical.com with an import confirmed registered via GET /api/v1/secret-imports:

   expandSecretReferences=true                        imports[] empty
   expandSecretReferences=true&includeImports=true    imports[] empty
   expandSecretReferences=true&include_imports=true   imports[] has the secret
   

   Imported secrets never appear in secrets. They come back in a separate imports array, one entry per source path — which the client wasn't reading at all.

   So Dokploy was asking with a flag the API ignores, and then looking in the wrong array.

   What the PR changes

   Sends include_imports=true, and merges imports[].secrets into the map before the folder's own secrets, so a name defined in both resolves to the local value — the way Infisical resolves it. Nothing changes for setups without imports: the array comes back empty.

   Worth confirming on your side

   This covers imports, including "Import Secrets → from another project", which is what your reproduction describes.

   Cross-project references — the ${@project-slug.env.KEY} value syntax from the docs link you posted — are a different mechanism, and I could not test them: that needs a second project plus the organization-level grant, which I don't have set up. If your case is actually that syntax inside a secret's value rather than an import, this PR won't be enough and it's worth saying so here, because the fix would be elsewhere.

   Two other measurements, in case they save you time

   • /api/v4/secrets returns imports with no flag at all.
   • Single-secret reads never see an imported key: /api/v3/secrets/raw/{name} gives 404, and /api/v4/secrets/raw/{name} isn't a route. A folder listing is the only way to reach them — which is why the 404 you saw is expected on that path even after the fix.
4. narcisonunez

   closed this as completedin #5414on Sep 10, 2026
5. pull

   added a commit that references this issue on Sep 10, 2026

   fix(vault): read Infisical secrets pulled in through an import

   ...

   This issue will close once commit 0c1dfe9 is merged into the 'canary' branch.

   0c1dfe9
6. cursor

   added a commit that references this issue on Oct 5, 2026

   fix(vault): read Infisical secrets pulled in through an import

   ...

   This issue will close once commit 2398f86 is merged into the 'canary' branch.

   2398f86
7. github-actions

   added a commit that references this issue on Oct 12, 2026

   chore(release): 0.42.0 [skip ci]

   ...

   63ce614