[robzolkos]

Why

Someone connecting their agent from My › Agent got asked by Claude to pick a lowercase profile name, and whether an older agent on their computer was the one they meant. The connect skill told it to: "Agree a profile name" in first-time setup, and "read last.json and confirm it" when no profile is named. Its trust options also reached people under their internal names (operator, allowlist, project).

What

In skills/basecamp-connect/SKILL.md:

• First-time setup, step 1. Use the profile the person names. Otherwise pick one yourself from the agent's name, and don't ask them to choose or confirm it.
• Invocation, step 1. Asked to connect a new agent, or one no profile here is connected as, go straight to first-time setup and don't ask about other agents' profiles.
• A taken name. If you chose a name that turns out to hold a person's login, pick another instead of asking.
• Who may give it work. Not asked. It's the operator alone unless they said otherwise, and the closing summary tells them so and that they can just ask to let others. When they do ask, each choice gets a plain sentence without the mode names. Setup runs once they've named the projects, without another confirmation.
• Plain words. Starting the connector, Claude tells the person their agent picks up work while this session is open, and leaves the connector, watcher, monitor and profiles unnamed.
• Identity, right after approval. The person chose the agent on the approval page, so Claude tells them its name and goes on instead of asking whether it's the right one. A profile that already held a credential still needs their word (unconfirmed-identity.yml).
• Projects. A personal agent is already in all of its owner's projects (Basecamp adds it on approval), so Claude serves every project the agent is in without asking, tells the person it picks up their requests in all of them and that they can ask it to skip some, and lists again after a moment if none show yet. Only an agent that isn't personal gets asked to be added somewhere. A project it joins later needs the person to ask. Ids stay out of what Claude says. When the agent can't list projects, Claude uses a profile that isn't an agent's, never another agent's. Before, Claude called the computer's other agent "your own login".

basecamp/bc3#13948 makes the matching change to the bootstrap that the My › Agent line points at. Its description has before and after transcripts of the whole flow.

Verification

• bin/ci passes, including skill drift.
• The model evals (make -C skill-evals eval-connect) didn't run, because they need ANTHROPIC_API_KEY. first-time-setup.yml names its profile in its context, which "Use the profile the person names" still honors.

---

Summary by cubic

Stops the Basecamp connect skill from asking people questions they can't answer, so connecting an agent from My › Agent no longer prompts them to pick a CLI profile name, confirm the agent they meant on this computer, or choose who may give it work.

• Claude picks the profile name itself from the agent's name, unless the person names one, and picks the next name (build-bot-2, then -3) if that one already holds another agent's or a person's login.
• Asked to connect a new agent, it goes straight to first-time setup and leaves other agents' profiles alone.
• Since the person chose the agent on the approval page, it names the agent and goes on instead of asking.
• Who may give the agent work isn't asked: unless the person already said otherwise, only the operator can, and setup runs once projects are named, without a final confirm.
• A personal agent is already a member of its owner's projects, so it serves all of them without asking and the owner's project list stands in when it can't list its own; for any other agent, it asks which of the projects it's in and the owner adds it where they want it. A project it joins later isn't served until the person asks.
• Starting the connector, it says the agent picks up work while this session is open, and leaves the connector, watcher, monitor and profiles unnamed.

^{Written for commit 36a232b. Summary will update on new commits.}

[Copilot]

🟢 Approved

The focused guidance changes preserve identity and credential safeguards, with no blocking issues identified; model evaluations remain unrun.

No open issues 🎉

What changed in this PR

Updates the agent-connect skill to avoid asking people about internal CLI details while preserving credential safeguards.

Changes:

• Choose profile names automatically unless the person supplies one.
• Route new agents directly to setup and avoid overwriting personal logins.
• Explain trust options without internal mode names.

[!TIP]
If you aren't ready for review, convert to a draft PR.
Click "Convert to draft" or run gh pr ready --undo.
Click "Ready for review" or run gh pr ready to reengage.

File	Description
skills/​basecamp-connect/​SKILL.md	Simplifies profile selection, setup routing, and trust explanations.

_{Review effort: Balanced}

[Copilot]

🟡 Changes recommended

The human-profile project fallback needs membership checks before treating returned projects as the agent’s projects.

1 open issue

• Avoid using person's projects as agent membership fallback · New

_{Review effort: Balanced}

[Copilot]

🔵 Needs a closer look

Automatically chosen profile names need collision handling when another agent already occupies the name.

1 open issue

• Avoid using person's projects as agent membership fallback

1 previously missed issue

In code that hasn't changed since last review

Retry automatically chosen names that belong to other agents

skills/​basecamp-connect/​SKILL.md:464

An automatically chosen name can also belong to another agent. For example, connecting a new “Helper” when helper holds a different agent follows the preceding oauth_type agent branch and skips approval. Identity confirmation then asks about the unrelated agent and stops setup when the person rejects it. For an automatically named new connection, leave occupied agent profiles untouched and retry with an unused name, just as for a person's login.

_{Review effort: Balanced}

[Copilot]

🔵 Needs a closer look

Automatically chosen profile names can collide with existing agent credentials and derail new-agent setup.

1 open issue

• Avoid using person's projects as agent membership fallback

1 previously missed issue

In code that hasn't changed since last review

Avoid profile name collisions with existing agent credentials

skills/​basecamp-connect/​SKILL.md:448

For a new-agent request, an automatically chosen name can collide with another agent's profile (for example, two names that normalize to helper). The oauth_type agent branch then skips connecting, and the identity check asks about the old agent or stops setup. When choosing a profile for a new agent, treat an existing agent credential as a taken name too: choose another name and check it before continuing.

_{Review effort: Balanced}

[Copilot]

🔵 Needs a closer look

Profile collisions and unverified fallback project memberships can prevent new-agent setup from completing.

1 open issue

• Avoid using person's projects as agent membership fallback

2 previously missed issues

In code that hasn't changed since last review

Auto-selected agent name can collide with existing profiles

skills/​basecamp-connect/​SKILL.md:448

An automatically chosen name can also collide with another agent's profile. For example, a new “Build Bot” can select build-bot even though that profile holds a different agent's credential. The oauth_type: agent branch then treats it as already connected, and the identity rule asks about the older agent or stops setup. For an explicitly new agent, choose an unused suffixed name instead; preserve identity confirmation when intentionally reusing an existing profile.

Fallback incorrectly uses the person's accessible projects

skills/​basecamp-connect/​SKILL.md:510

The fallback lists the person's accessible projects, not the agent's memberships. A shared agent might belong to Redesign while the person also sees Marketing. Treating both results as the agent's projects makes setup fail when it checks Marketing as the agent (internal/connector/setup/checks.go:404–428). Before applying the serve-all default, scope the fallback to the agent's account and verify membership using each project's people list.

_{Review effort: Balanced}

[robzolkos]

Answering the two findings from Copilot's review summaries that have no thread. Both are fixed in 36a232b.

• An auto-chosen name can collide with another agent's profile (SKILL.md, first-time setup step 1). Fixed. When Claude chose the name for a new agent and auth status shows an agent already there, it's another agent's profile. Claude leaves it alone and tries the next name (build-bot-2, then -3). A profile the person named keeps the old meaning: it's already connected, and Claude doesn't connect again.
• The fallback lists the person's projects, not the agent's (step 3). Fixed, as in the thread. The person's list counts as the agent's only for a personal agent. For any other agent, Claude asks.

bin/ci passes on 36a232b.

[Copilot]

🔵 Needs a closer look

Fallback project discovery must use the agent's account to avoid selecting unrelated projects for multi-account users.

No open issues 🎉

1 previously missed issue

In code that hasn't changed since last review

Pin fallback project listing to the agent's bound account

skills/​basecamp-connect/​SKILL.md:512

Pin the fallback project listing to the agent's account. A person's profile can default to a different account (internal/config/config.go:707–709), while connector setup uses the agent profile's bound account (internal/commands/connect.go:1004–1030). The new serve-all default can therefore select unrelated project IDs and fail setup for multi-account users, even when the personal agent follows its owner. Pass --account with the agent's bound account when listing through the person's login.

1 resolved since last review

• Avoid using person's projects as agent membership fallback

_{Review effort: Balanced}

[robzolkos]

Answering the finding in Copilot's review of 36a232b, pin the fallback project listing to the agent's bound account (SKILL.md, step 3). Fixed in b2577f2. The fallback lists the person's projects with --account set to the account_id the agent's auth status reports, because the person's login may default to another account. That's the same reason the skill already gives for reading the operator's name. bin/ci passes.

[robzolkos]

This merged at 36a232b, before b2577f2 landed, so the account fix from my last comment isn't in main. It's in #920.