Repository navigation
[Bug]: Cannot delete orphaned project after environment is gone #4851
Description
Area
apps/web / project management
Summary
An orphaned T3 Code project cannot be deleted after its original environment/machine is gone.
Affected project
- Project ID:
59025a7f-1c36-44e0-8960-5f804f645280 - Display name:
dev-network - Workspace path:
/home/spade/projects/dev-network - Environment:
devbox
The original machine named/aliased devbox no longer exists. A replacement machine uses the same alias but does not contain this workspace or project record.
Steps to reproduce
- In T3 Code, locate the bottom
dev-networkproject. - Choose Remove project.
- Confirm removal.
- The operation fails because the project still has threads.
- Try the CLI force-delete path.
Expected behavior
A project should be force-deletable by project ID even when its environment is offline or permanently gone, its workspace path no longer exists, and it still contains threads.
Actual behavior
The UI confirmation fails with:
Orchestration command invariant failed (project.delete):
Project '59025a7f-1c36-44e0-8960-5f804f645280' is not empty
and cannot be deleted without force=true.
The CLI accepts --force, but the command still cannot remove the orphaned project. Passing the project ID produces:
ProjectNotFoundError: No active project found for '59025a7f-1c36-44e0-8960-5f804f645280'
WorkspaceRootNotExistsError:
Workspace root does not exist:
/home/spade/59025a7f-1c36-44e0-8960-5f804f645280
Passing the displayed workspace path also fails because the original path does not exist on the replacement machine:
ProjectNotFoundError: No active project found for '/home/spade/projects/dev-network'
WorkspaceRootNotExistsError:
Workspace root does not exist: /home/spade/projects/dev-network
Impact
The orphaned project remains permanently visible in the UX and cannot be removed through either the UI or CLI. Recreating the path on the replacement machine does not restore the original project identity/environment and is unsafe because similarly named projects exist.
Suggested fix
- Allow the project-delete orchestration command to accept
force: truefrom both the UI and CLI. - Resolve deletion by project ID without requiring the workspace path to exist.
- Permit force deletion of the project and all child threads when the environment is permanently unavailable.
- Ensure the CLI's
--forceflag is actually forwarded asforce: true.
Workaround
None when the original environment/machine no longer exists.
Activity
[-][Bug]: Can't delete orphaned project[/-][+][Bug]: Cannot delete orphaned project after environment is gone[/+]juliusmarminge commentedon Sep 5, 2026
The September 4, 2026 audit found a narrow CLI lookup bug and merged its fix in #9885, now on main at 9cb40178. When the selected environment still owns the project record, its exact stored workspace path can now identify it for rename/removal even after that directory disappears. Ten focused tests exercise the actual CLI and disposable SQLite state, including force/thread rules and separate symlink entries.
This does not resolve the original unavailable-environment/client-cache case. Removing by project ID already works in an environment that retains the record, and both current UI delete callers use that ID with
force: true. A replacement environment with an empty database cannot delete the old environment's record. Forgetting that orphaned client entry needs a separate product decision, so this issue remains open.GPT 6 Astra via Codex in T3 Code.
juliusmarminge commentedon Oct 22, 2026
Tested on Linux in the web dev app at main 89fe509232, using isolated state:
dev-networkwith a persisted thread, removed its workspace directory, then used Remove project → Confirm. Both project and thread were deleted successfully.project remove <id> --forceandproject remove <stored-path> --forceboth succeeded after their directories were removed.project.delete/not emptyinvariant did not appear. This does not verify replacement-machine behavior.Missing-directory CLI lookup was fixed in 9cb40178a5. Current web removal also sends
force: true.What client and server versions are you using now? After a full reload connected only to the replacement
devbox, does the old entry still appear, and what exact error does removing it produce? This will distinguish stale client state from a surviving project record on a server.Before confirmation, with the directory absent:
After confirmation, the project is gone:
github-actions commentedon Oct 29, 2026
Closing: no reply in 7 days after we asked for more information. Comment with the missing details and we will reopen.