> For the complete documentation index, see [llms.txt](https://docs.flatredball.com/gum/llms.txt). Markdown versions of documentation pages are available by appending `.md` to page URLs; this page is available as [Markdown](https://docs.flatredball.com/gum/gum-tool/code-tab/orphaned-code-files.md). # Orphaned Code Files Code generation writes `.cs` files to a folder outside your Gum project. When you delete, rename, or move an element, the files that were generated for it can be left behind. SDK-style `.csproj` files include every `.cs` file under the project folder, so a leftover file keeps compiling forever without any warning. Gum scans for these files when you load a project, and on demand through **Content** > **Scan for Orphaned Code Files**. Anything it finds appears in the [Errors tab](/gum/gum-tool/editor-tab.md) as a **GUM0005** entry with a **Delete File** button. {% hint style="info" %} Available in September 2026, or now if building Gum from source. {% endhint %} ## What the Scan Reports * **Generated code files** (`MyScreen.Generated.cs`) with no matching element. These are recreated exactly by regenerating the element, so deleting one loses nothing. The **Delete File** button moves it to the Recycle Bin immediately. * **Custom code files** (`MyScreen.cs`) sitting next to an orphaned generated file. These contain your own code, so Gum asks you to confirm before moving the file to the Recycle Bin. * **Element code settings files** (`MyScreen.codsj`) alongside the element XML, holding the per-element settings shown on the **Code** tab. Gum confirms before removing these too. ## What the Scan Does Not Report Detection is deliberately conservative, so it never flags a file Gum did not write: * **Extra hand-written partial classes.** If you add your own `MyScreen.Input.cs` partial, Gum has no knowledge of it and never reports it, even after the element is deleted. Remove those files yourself. * **Files with a Generation Behavior of `NeverGenerate`.** Those elements are hand-managed, so Gum leaves their files alone. * **Elements whose source file is missing.** The element is still part of the project, so its code files are not orphans. That situation is reported separately as [GUM0004](/gum/gum-tool/project-files.md). * **Generated files written by other tools.** Gum only recognizes a `.Generated.cs` file that carries the header its own code generation writes. * **Custom code you chose to keep.** Deleting an element removes its generated file, and leaves the custom `.cs` file whenever you leave **Delete custom code file (contains your code)** unchecked. Gum finds an orphaned custom file through its generated file, so once that generated file is gone the custom one is no longer reported. Delete it yourself if you later change your mind. ## Cleaning Up From the Command Line `gumcli codegen --prune` regenerates the project and then deletes generated files with no matching element. This is often the better option for a project already under source control: it is explicit, it handles every file at once, and the result shows up as a reviewable diff. `--prune` never deletes custom code or `.codsj` settings files. It lists them so you can decide. --- # Agent Instructions This documentation is published with GitBook. GitBook is the documentation platform designed so that both humans and AI agents can read, navigate, and reason over technical content effectively. Learn more at gitbook.com. ## Querying This Documentation If you need additional information that is not directly available in this page, you can query the documentation by asking a question. Perform an HTTP GET request on the following URL with the `ask` and `goal` query parameters: ``` GET https://docs.flatredball.com/gum/gum-tool/code-tab/orphaned-code-files.md?ask=&goal= ``` `ask` is the immediate question: it should be specific, self-contained, and written in natural language. `goal` is what the user is ultimately trying to achieve, the reason they need the answer. Sharing it helps GitBook give you a better, more relevant answer. A goal is most helpful when it describes the outcome the user wants rather than restating the question. For example, with `ask=how do I create an API token`, a goal like `automate deployments from our CI pipeline` lets GitBook tailor the answer to that use case. The response will contain a direct answer to the question and relevant excerpts and sources from the documentation. Use this mechanism when the answer is not explicitly present in the current page, you need clarification or additional context, or you want to retrieve related documentation sections.