Can I get some clarity around how secret deletion is scoped during GH secret syncing? For a single infisical project, I have 3 syncs. One syncs a set of secrets to a GH repo, and two others each for ENV-specific secrets for that same repo. If I turn on secret deletion, what secrets will be deleted? I think I should be good to go since each sync targets a different location (repo level vs, two specific ENVs) but I wanted a bit of clarity. When I turn this on, will it remove from each destination any secrets not included in infisical?

Hi @David Konigsberg, each sync only deletes secrets from its own specific destination. Your 3 syncs won't interfere with each other. • Repo-level sync → only touches repo-level Actions secrets • Env sync (e.g. staging) → only touches secrets in that specific GH environment • Env sync (e.g. production) → only touches secrets in that specific GH environment When deletion is enabled, a sync will remove any secret at its destination that isn't in the Infisical source for that sync. It won't reach into other scopes. If you're also using a key schema, it's even safer, as only secrets matching the schema pattern are considered for deletion.

Perfect, makes sense, just wanted to be sure before flipping the switch. Thanks!

Hi @David Konigsberg, those two syncs will conflict with each other if you enable deletion on both. Both syncs hit the same org-level secrets endpoint on GitHub. The visibility setting (all repos vs private repos) only matters when writing secrets; when listing secrets for deletion, GitHub returns everything at the org level regardless. So what happens is each sync sees the other sync's secrets, doesn't recognize them as its own, and deletes them. Then the other sync runs and does the same thing back. A potential fix is to use a key schema (e.g.

{{environment}}_{{secretKey}}

) so each sync's secrets have a distinct prefix. The deletion logic will then skip any secrets that don't match its own schema pattern, and they'll leave each other alone.

Gotcha, disabling deletion for now. The namespacing is a good idea, but significantly increases the migration lift as I would need to update the secrets everywhere they are used. In any case, thanks for the quick response!

Of course!