Should the default AppProject be shown as an orphaned resource?

[reschandreas]

Hi!

I've got a question about the handling of orphaned resources.

Context

Yesterday I accidentally put our argo-cd cluster in a weird limbo state by deleting orphaned resources.

What did I do?

• Enabled warning of orhpaned resources to clean up our clusters.
• Started looking through the UI to find resources that can be deleted.
• Found the kind: AppProject with name default, cross-checked and did not find any references to it in our GitOps (we have multiple projects) so i hit delete -> this meant that now all resources were shown as orphaned, the deployments kept running, the cluster itself was still looking good, but kinda all resources except ApplicationSet were orphaned.

Solution

We fixed it in the end by adding the cluster again with the argocd cli tool.

Questions

1. Searching through the web I found suggestions to just add the AppProject default again with kubectl but we decided against it as we were not sure if that would disrupt the running deployments. Would that also have worked?
2. Should it even be possible to delete this specific AppProject? It says here that the project can not be deleted, but I did manage to do so through the argo-cd UI.
3. Should the default AppProject maybe be added as an excemption to the orphaned resources warning such as the default serviceaccount? I don't want people to repeat my mistake :)

Thank you so much!

P.S.: If indeed the default AppProject should be excluded, I'd me more than happy to contribute that change to the codebase and the documentation

[abhay1999]

This is a really good catch, and I think you’ve identified a genuine UX safety gap. Let me answer each question:

---

1. Would kubectl apply have worked to restore the default AppProject?

Yes, absolutely. Running:

kubectl apply -f - <<EOF
apiVersion: argoproj.io/v1alpha1
kind: AppProject
metadata:
  name: default
  namespace: argocd
spec:
  clusterResourceWhitelist:
  - group: '*'
    kind: '*'
  destinations:
  - namespace: '*'
    server: '*'
  sourceRepos:
  - '*'
EOF

would have restored the project without disrupting any running deployments. Kubernetes Deployments, Services, etc. are managed directly by the Kubernetes controllers — they don’t have a runtime dependency on the AppProject object. The AppProject is only consulted by Argo CD at sync time to check permissions.

---

2. Should deletion of the default AppProject be possible through the UI?

This looks like a bug. The docs state it cannot be deleted, and the CLI enforces that protection:

FATAL[...] permission denied

But the UI apparently bypasses that guard. This is worth filing as a separate bug report — the UI should respect the same deletion protection that the CLI and API enforce.

---

3. Should default AppProject be excluded from orphaned resources warnings?

Yes, I strongly agree. The default AppProject is a system-managed resource that Argo CD itself relies on for correct operation — much like the default ServiceAccount in Kubernetes. Showing it as an orphaned resource is actively misleading and, as you discovered, dangerous.

The precedent is already set in the codebase: Argo CD excludes certain well-known system resources from orphaned resource warnings. The default AppProject should be in that list.

Where to make the change

If you want to contribute the fix, the relevant place to look is the orphaned resources reconciliation logic:

• controller/appcontroller.go — isOrphanedResource() or similar filtering function
• You’d add a check: if resource.Kind == "AppProject" && resource.Name == "default", skip it
• Docs update: docs/operator-manual/orphaned-resources.md

Also worth adding a note in the Projects docs that the default project should never be deleted.

Great that you’re willing to contribute the fix — this would be a valuable improvement for anyone managing Argo CD clusters!