Skip to content

Linked-machine project labels show the owner even for your own repos ("EtanHey/orchestrator") #26296

Open

Description

@EtanHey

Problem

A project saved as orchestrator on both Macs displays as EtanHey/orchestrator when the client combines those records into a shared group. A single-machine project keeps its plain title. Linking the second machine therefore changes the visible name despite identical saved names.

Current source: packages/client-runtime/src/state/projectGrouping.ts:201–238, deriveProjectGroupLabel. A shared title equal to the repository name bypasses the custom-title return; the function then prefers repository displayName, which contains the owner. Renaming both records to the repo name cannot fix the visible label.

Proposed behavior

Omit the owner when it matches the signed-in repository-provider account. Keep the owner for other accounts or organizations: own EtanHey/orchestrator becomes orchestrator; official pingdotgg/t3code remains pingdotgg/t3code when signed in as EtanHey. Preserve explicit custom project names.

Use verified provider identity, not the macOS username, an inferred remote owner, or a global string replacement. This label function currently receives projects only; the identity input and unavailable-identity behavior need an upstream design decision. With unknown identity, keep the qualified label. Retain owner qualification when needed to distinguish otherwise colliding labels.

Change presentation only. Keep repository grouping keys, fork/upstream selection, environment links, load balancing, stored titles, icons and thread ownership unchanged. Apply the shared helper consistently to web/desktop and mobile consumers.

Proposed focused acceptance cases

  • Linked own repositories: plain title before and after adding another machine.
  • Foreign repository and own fork shown together: correct owner remains distinguishable.
  • Case-insensitive provider-login match; unknown account retains owner.
  • Explicit custom title remains unchanged.
  • Shared group, destination environment and thread placement remain unchanged.

No patch, installed-app modification, issue, comment or PR was created. Source diagnosis is verified; proposed behavior is not implemented or tested.

Activity

  1. EtanHey commented on Oct 28, 2026

    @EtanHey
    ContributorAuthor

    Rechecked on 2026-10-28 through T3 Code's built-in triage playbook with Codex / GPT-6.1 Sol.

    Executed deriveProjectGroupLabel from both v0.1.4-nightly.20261028.3814 (installed/running) and v0.1.4-nightly.20261028.3824 (latest published, source only). Two project records titled orchestrator, with repository name orchestrator and repository display name EtanHey/orchestrator, still produce EtanHey/orchestrator on both tags.

    The shared label helper is unchanged: a title equal to the repository name bypasses the custom-title branch, then the shared repository display name wins. It still has no signed-in provider-identity input. The newer multi-machine orchestration capabilities do not alter that presentation rule.

    Keeping this open. This is an executed source-function check, not fresh visual acceptance on either app surface or a live .3824 run.

  2. added 5 commits that reference this issue on Nov 3, 2026
    0e84c33
    ca4a701
    f3905ba
    b6333df
    3704c38
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment

Metadata

Metadata

Assignees

No one assigned

    Labels

    No labels
    No labels

    Type

    No type

    Projects

    No projects

      Milestone

      No milestone

      Relationships

      None yet

      Development

      No branches or pull requests

      Issue actions