[Bug]: Renaming projects removing the grouping part but keeping the repo name does not saves and keeps the original name#15049

Triage

Thanks for the report and the recordings, @alanmoyano.

Confirmed, and still present on main. For grouped projects (ones with more than one checkout), the sidebar and settings don't show the stored title directly. deriveProjectGroupLabel only counts a shared title as custom when it differs from both the repository display path and the repository name. Otherwise it falls back to repositoryIdentity.displayName, the path under the host: pingdotgg/t3code on GitHub, or group/subgroup/repo on GitLab.

The default title is the folder name, which is usually the repository name. So when you delete the owner or group prefix and keep just the repo name, you end up with exactly the value the label logic ignores, and it snaps back to the full path. The settings field remounts from that derived label, so it reverts there too. Any other name, like t3code2, sticks.

A second check affects the same edit. If every member's title already equals the repo name, projectGroupTitleNeedsUpdate skips the write entirely. And if a different name was saved earlier, the write goes through but the label still falls back to the display path.

The fallback exists so that a default folder title doesn't replace owner/repo in the sidebar. The bug is that it also blocks an explicit rename to the plain repository name. Mobile uses the same label helper, so it's affected as well. #7510 and #7831 fixed an earlier version of this, but that fix didn't cover renaming to exactly the repository name.

Still reproducible on macOS with 0.0.46-nightly.20261013.3066. Renaming a grouped project from owner/repo to repo restores the org prefix. Using Repo instead persists and removes the prefix.

I hit this today on the current nightly with a project that has two checkouts, and I've opened a fix in #23074.

Following the triage above, it keeps the default and honors explicit renames. The server now records when a project's title was set by hand. Grouped labels use the shared title whenever someone has renamed it, and groups nobody renamed still show owner/repo. The settings field also saves a rename even when the folder titles already match, which was the second cause noted in the triage.

The PR has before/after screenshots and replaces #15212, which was closed for its model.

Reproduced on Linux web dev at b5a226e49c, with isolated state and two local checkouts sharing an acme/demo origin. In Settings → Project, changing acme/demo to demo and blurring leaves the group label unchanged; reload restores acme/demo in the field. A different name, demo-custom, does update the group label.

Recording: rename, blur, reload. Cross-machine and native macOS behavior were not checked. Existing contributor fix: #23074.

This also reproduces across machines, which the repro above didn't cover. One GitHub repository is added as a project on two separate T3 Code environments. Both projects have the stored title repo and the same repository identity, and the grouped row shows owner/repo. Projects that exist on only one environment show their plain title. Same cause as the triage: the stored title equals the repository name, so deriveProjectGroupLabel falls back to the display path.

The current fix is #25244 (takes over #23074). CI is green, Macroscope approved it, and it was verified end to end on 2026-10-28. It is now conflicting with main only because its new migration is numbered 070_ProjectionProjectsCustomTitle, and main already has migrations 070 to 072. The conflicts are in apps/server/src/persistence/Migrations.ts and reconcileV2PreviewMigration.test.ts. Renumbering it to 073 should be all it needs before review.

Also hitting this on 0.1.3 (Linux server). My project entity/charliej.com won't rename to charliej.com and keeps reverting to entity/charliej.com. Other names like hi or charliej.co stick fine. Looking forward to #23074 landing.