Argo CD prune scope for untracked resources in shared namespaces

Answer

With syncPolicy.prune: true Argo CD will not delete Kubernetes resources it has never tracked, even when those resources share a namespace with tracked resources. Prune scope is limited to the Application's declared manifest set and the live objects Argo CD knows it created or synced for that Application. Untracked, externally created objects are preserved.

Confirmed facts

• Prune only removes resources Argo CD previously created or synced for the Application and that are now absent from the Git desired state.
• syncPolicy.prune=true does not provide namespace-wide garbage collection. Scope is the Application's manifest set and the live objects Argo CD tracks for that Application.
• Prune executes during normal application reconciliation and sync, not immediately after a Git commit. Action time depends on controller resync interval, sync triggers, and sync duration.
• There is no built-in operator setting to make Argo CD prune untracked resources in the same namespace as tracked resources. Namespace-wide pruning of untracked objects requires external tooling outside Argo CD.

Likely explanation

Externally created resources sharing a namespace with tracked resources are left untouched by prune. Indirect removal can only occur if the external resource is an owned child of a tracked parent that is itself pruned and Kubernetes cascade delete applies. Shared namespaces increase risk of accidental deletion if Application manifests are broadened or resource tracking changes.

Steps needed for this case

1. Inspect the Application spec for spec.syncPolicy.prune and the resource tracking method in use.
2. Confirm which live objects are considered managed by checking Argo CD tracking annotations on resources in the namespace.
3. Review Argo CD controller logs for reconciliation and prune actions and compare the desired manifest list against live resources.
4. Test prune behavior in a non-production namespace with a dummy untracked resource to observe it is preserved after a sync with prune enabled.

Timing to assume

Expect prune to act on a resource removed from Git only after the next successful reconciliation and sync for the Application. That is driven by the controller resync interval, webhook/git events, and manual sync triggers, not by commit time.

One missing diagnostic detail that changes the recommendation: do any external resources have ownerReferences to a tracked parent that may be pruned? If yes, Kubernetes cascade delete can indirectly remove them even though prune itself targets only tracked objects.