Movatterモバイル変換


[0]ホーム

URL:


Skip to content

Navigation Menu

Sign in
Appearance settings

Search code, repositories, users, issues, pull requests...

Provide feedback

We read every piece of feedback, and take your input very seriously.

Saved searches

Use saved searches to filter your results more quickly

Sign up
Appearance settings

fix(cli)!: enforce selection for multiple agents and select sub agent if available#18427

New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to ourterms of service andprivacy statement. We’ll occasionally send you account related emails.

Already on GitHub?Sign in to your account

Open
mafredri wants to merge2 commits intomain
base:main
Choose a base branch
Loading
frommafredri/fix-cli-agent-selection

Conversation

mafredri
Copy link
Member

@mafredrimafredri commentedJun 18, 2025
edited
Loading

In the past we randomly selected workspace agent if there were multiple.
Unless both are running on the same machine with the same configuration,
this would be very confusing behavior for a user.

With the introduction of sub agents (devcontainer agents), it was
decided prioritize them if present. Similarly as before, selecting a
devcontainer randomly would be confusing. We now error out if the agent
name is not specified and there are multiple agents.

Fixescoder/internal#696

Example output from running two devcontainers:

Encountered an error running "coder ssh", see "coder ssh --help" for more informationerror: multiple sub-agents found, please specify the agent name, available agents: [dev magical-easley tender-carson]

TBD: Do we classify this breaking or not? IMO it could slip by as not as random selection can't really be a feature, can it? And dev containers are new and you can just not use them.

In the past we randomly selected workspace agent if there were multiple.Unless both are running on the same machine with the same configuration,this would be very confusing behavior for a user.With the introduction of sub agents (devcontainer agents), it wasdecided prioritize them if present. Similarly as before, selecting adevcontainer randomly would be confusing. We now error out if the agentname is not specified and there are multiple agents.Fixescoder/internal#696
@mafredrimafredriforce-pushed themafredri/fix-cli-agent-selection branch from0a47fd1 to647181eCompareJune 18, 2025 13:07
@mafredrimafredri marked this pull request as ready for reviewJune 18, 2025 15:03
@github-actionsgithub-actionsbot added the release/breakingThis label is applied to PRs to detect breaking changes as part of the release process labelJun 18, 2025
@mafredrimafredriforce-pushed themafredri/fix-cli-agent-selection branch from1c6193a tof923edbCompareJune 18, 2025 15:06
@johnstcn
Copy link
Member

TBD: Do we classify this breaking or not? IMO it could slip by as not as random selection can't really be a feature, can it? And dev containers are new and you can just not use them.

IMO if you have to ask yourself if this is a breaking change, it's best to err on the side of caution and label it as breaking (obligatory:https://xkcd.com/1172/).

@mafredrimafredri changed the titlefix(cli)!: select sub agent if available and error on multiple agentsfix(cli)!: enforce selection for multiple agents and select sub agent if availableJun 18, 2025
@johnstcn
Copy link
Member

@mafredri my understanding of this change is as follows:

Given: workspace foo, agent smith, no sub-agents
Then:

  • coder ssh foo maps to agent bar
  • coder ssh foo.bar maps to agent bar

Given: workspace foo, agents smith, jones
Then:

  • coder ssh foo fails
  • coder ssh foo.smith maps to agent smith
  • coder ssh foo.jones maps to agent jones

Given: workspace foo, agents smith, sub-agents johnson
Then:

  • coder ssh foo maps to agent smith
  • coder ssh foo.smith maps to agent smith
  • coder ssh foo.johnson maps to agent johnson

Given: workspace foo, agents smith, sub-agents johnson, thompson
Then:

  • coder ssh foo maps to agent smith
  • coder ssh foo.smith maps to agent smith
  • coder ssh foo.johnson maps to agent johnson
  • coder ssh foo.thompson maps to agent thompson

Given: workspace foo, agents smith, johnes, sub-agents johnson, thompson
Then:

  • coder ssh foo fails
  • coder ssh foo.smith maps to agent smith
  • coder ssh foo.jones maps to agent jones
  • coder ssh foo.johnson maps to agent johnson
  • coder ssh foo.thompson maps to agent thompson

Am I correct?

@mafredri
Copy link
MemberAuthor

mafredri commentedJun 18, 2025
edited
Loading

@johnstcn Close, just two correction (as sub agents are prioritized same as in the Web UI).

Given: workspace foo, agents smith, sub-agents johnson
Then:

  • coder ssh foo maps to agent smithThis maps to johnson

Given: workspace foo, agents smith, sub-agents johnson, thompson
Then:

  • coder ssh foo maps to agent smithThis errors, two sub agents

@johnstcn
Copy link
Member

Given: workspace foo, agents smith, sub-agents johnson Then:

  • coder ssh foo maps to agent smithThis maps to johnson

On the surface I find this mildly surprising, but given that it's predicated on the presence of a sub-agent and that it corresponds with the UI's prioritization, that seems fine to me.

Copy link
Member

@johnstcnjohnstcn left a comment

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others.Learn more.

Approving pending any blocking concerns from@deansheather

Sign up for freeto join this conversation on GitHub. Already have an account?Sign in to comment
Reviewers

@johnstcnjohnstcnjohnstcn approved these changes

@deansheatherdeansheatherAwaiting requested review from deansheather

@DanielleMaywoodDanielleMaywoodAwaiting requested review from DanielleMaywood

Assignees

@mafredrimafredri

Labels
release/breakingThis label is applied to PRs to detect breaking changes as part of the release process
Projects
None yet
Milestone
No milestone
2 participants
@mafredri@johnstcn

[8]ページ先頭

©2009-2025 Movatter.jp