Reported by Jay 2026-07-21 after onboarding the taOSmobile agent, which arrived as taosmobile-claude-taosmobile-dev.
The duplication
_derive_handle in tinyagentos/routes/project_invites.py builds {project_slug}-{harness}[-{label}]. When the agent's chosen label already contains the project name, which is the natural thing for someone to type, the project name appears twice:
| input |
result |
project taosmobile, harness claude, label taosmobile-dev |
taosmobile-claude-taosmobile-dev |
It is not wrong, just unusable as a name. Jay renamed it by hand via PATCH /api/agents/registry/{id}.
Fix
Before joining the parts, drop any component already contained in another:
- If the slugified label starts with or equals the project slug, do not prepend the project slug again.
- Same check for the harness, so
claude plus label claude-code-dev does not become claude-claude-code-dev.
Keep the collision suffix behaviour (-2, -3) unchanged.
Worth deciding at the same time
The harness in the middle of a handle is questionable. taosmobile-claude-dev tells a human that the agent runs on Claude Code, which is an implementation detail that changes when the harness is swapped (harness swapping is explicitly supported). A handle should probably be a name, not a spec. Consider {project}-{label} with harness kept as a field rather than baked into the identity string.
Also
There is no UI for renaming a handle. Card tsk-kqffyv (alias editing in the Agents app) was closed, so either it did not cover the registry handle or it regressed. Jay should not need an API call to fix a name.
Related: #1972 (human-friendly project IDs, same class of naming problem).
Reported by Jay 2026-07-21 after onboarding the taOSmobile agent, which arrived as
taosmobile-claude-taosmobile-dev.The duplication
_derive_handleintinyagentos/routes/project_invites.pybuilds{project_slug}-{harness}[-{label}]. When the agent's chosen label already contains the project name, which is the natural thing for someone to type, the project name appears twice:taosmobile, harnessclaude, labeltaosmobile-devtaosmobile-claude-taosmobile-devIt is not wrong, just unusable as a name. Jay renamed it by hand via
PATCH /api/agents/registry/{id}.Fix
Before joining the parts, drop any component already contained in another:
claudeplus labelclaude-code-devdoes not becomeclaude-claude-code-dev.Keep the collision suffix behaviour (
-2,-3) unchanged.Worth deciding at the same time
The harness in the middle of a handle is questionable.
taosmobile-claude-devtells a human that the agent runs on Claude Code, which is an implementation detail that changes when the harness is swapped (harness swapping is explicitly supported). A handle should probably be a name, not a spec. Consider{project}-{label}with harness kept as a field rather than baked into the identity string.Also
There is no UI for renaming a handle. Card
tsk-kqffyv(alias editing in the Agents app) was closed, so either it did not cover the registry handle or it regressed. Jay should not need an API call to fix a name.Related: #1972 (human-friendly project IDs, same class of naming problem).