Renaming a deployment's tracing project breaks the deployment link and reserves the name

Last updated: September 30, 2026

Symptom

A LangGraph Platform deployment's hosted runs stop showing up under the tracing project you expect. This happens after someone renames the tracing project itself from its Settings page, instead of renaming the deployment.

Once the deployment sends its next hosted run, the platform can't find a tracing project matching the deployment's name anymore, so it auto-creates a new tracing project under the original name. New traces land in that new project, split from the older history. If this cycle repeats, duplicate auto-created projects can pile up under the original name.

Trying to rename your intended project back to the original name fails with an HTTP 409 ("project name already exists"), even though no project you can see appears to hold that name. The name is reserved by the deployment's own auto-created project record, not by anything visible or deletable from your side.

Cause

A LangGraph Platform deployment's name doubles as the name of its associated tracing project. Renaming the tracing project directly breaks that link. The next hosted run then auto-creates a fresh tracing project under the deployment's original name to keep the deployment-to-project link consistent.

The original name becomes permanently reserved by that auto-created project. It can't be reused by another project through the rename API, and deleting the new auto-created project doesn't free the name up either. This is by design, not a bug. Because reversing it risks breaking other links, it isn't something that can be safely undone with a one-off fix.

Resolution

To avoid this, rename a deployment through its own display name setting in deployment Settings, not by renaming its tracing project. The display name is just a label. It doesn't affect where traces are routed and doesn't decouple the deployment from its tracing project or touch the deployment's URLs or infrastructure.

If the tracing project has already been decoupled from the deployment:

  • There's no way to reclaim the original reserved name for your canonical project.

  • Keep the old tracing project around for its historical traces.

  • Use the public langsmith-data-migration-tool to carry over most settings (project rules/automations, charts, evaluator configuration) from the old project to the new auto-created project. The tool can't migrate the historical traces themselves into the new project.

If you need the exact original name back, recreate the deployment under a new name, and separately arrange for full cleanup of the old, reserved name's tracing data and settings. Only after that cleanup is complete can a new deployment use the originally desired name.

References