No way to scope an externally-registered tool away from sub-agents
Mantenedores costumam responder em até 8 dias
Ninguém assumiu esta issue ainda.
Avaliação
- Dificuldade
- 5/5
- Tempo estimado
- Mais de uma semana
- Facilidade para iniciantes
- 35/100
Direção de pesquisa
Comece rastreando SessionConfig.tools e ResumeSessionConfig.tools até Tool, DefaultAgentConfig, CustomAgentConfig e a configuração dos subagentes integrados. Compare os designs propostos de disponibilidade no nível de Tool e exclusão no nível do agente; considera-se concluído quando uma ferramenta registrada puder permanecer disponível para o agente primário e indisponível para os subagentes integrados, sem remover esses agentes.
Escrita pelo modelo de indexação a partir do texto da issue.
Descrição
An SDK consumer registers external tools via SessionConfig.tools / ResumeSessionConfig.tools. Those tools reach the default agent and are inherited by sub-agent runs, including built-in ones (task, explore, …). There is no supported way to express "this tool is for the top-level agent only."
The existing controls are asymmetric
DefaultAgentConfig.excluded_toolshides a tool from the default agent while keeping it available to sub-agents — precisely the opposite of what's needed. (Its own doc comment says so: "hide tools from the default agent while keeping them available to custom sub-agents that list them in theirCustomAgentConfig::tools".)CustomAgentConfig.toolsis a per-custom-agent allowlist, so it only constrains agents the consumer defines. Built-in sub-agents can't be reached this way.excluded_builtin_agentsremoves the sub-agent outright — far too coarse, and it disables capability the consumer still wants.
Why this is general
Many externally-registered tools are either:
- UI-bound — they drive a picker, a canvas, an editor, or another foreground surface that only exists for the conversation the user is actually looking at. A background sub-agent has nothing to drive.
- Acting with the user's authority in a third-party system — posting messages, filing tickets, sending mail, spending money. Autonomous invocation from a delegated worker is the wrong default.
Neither of those is specific to one embedder; both follow from the tool being executed outside the agent loop, on behalf of a user who is present in exactly one conversation.
Ask
A way to declare this at registration. Two shapes seem plausible:
- A field on
Tool, e.g.availability:session(default) |primary-agent-only. - A
DefaultAgentConfig-symmetric sub-agent config carryingexcluded_tools.
The Tool-level field seems stronger: the constraint belongs to the tool rather than to one agent's configuration, so it keeps holding as new built-in agents are added, and a consumer registering a tool doesn't have to enumerate the agent set to protect it.
Current workaround
Refusing the invocation after the fact — the host answers the tool call with a failure instead of executing it. That works, but it costs a model turn, hands the model an error it may retry against, and gives no way to express that the tool simply isn't available in that context. The tool stays in the sub-agent's tool list either way.
- Linguagem predominante
- Java
- Estrelas
- 10.6k
- Forks
- 1.5k
- Métricas de merge de PRs
- Nenhum PR com merge em 30d
Preparar o ambiente
Inicia o contêiner de desenvolvimento do projeto no navegador, com a sua própria conta do GitHub.
- Sem Dockerfile nem arquivo Docker Compose
- Sem modelo de pull request
- Ler o guia de contribuição
Primeiros passos
- Leia a issue inteira e depois o guia de contribuição do projeto.
- Comente na issue dizendo que vai assumir — evita que duas pessoas façam o mesmo trabalho.
- Faça um fork do repositório e trabalhe em uma branch.
- Abra um pull request que referencie o número da issue.
Mais de github/copilot-sdk
-
Clarify SDK architecture and in-process runtime transportTalvez já em andamento @KalebCole assumiu há 23 dias. Abertadocumentation
Dificuldade 1/5 Menos de uma hora Facilidade para iniciantes 92/100
github/copilot-sdk#2804 · 1 comentário ·
Mantenedores costumam responder em até 8 dias
-
Python ModelLimits drops max_output_tokens from model metadataTalvez já em andamento @HDMowri assumiu há 25 dias. Abertabug
Dificuldade 2/5 1-3 horas Facilidade para iniciantes 78/100
github/copilot-sdk#2798 · 1 comentário ·
Mantenedores costumam responder em até 8 dias
-
Dificuldade 2/5 1-3 horas Facilidade para iniciantes 76/100
github/copilot-sdk#2793 ·
Mantenedores costumam responder em até 8 dias
-
agentic-workflows
Dificuldade 2/5 1-3 horas Facilidade para iniciantes 68/100
github/copilot-sdk#2782 ·
Mantenedores costumam responder em até 8 dias
-
agentic-workflows
Dificuldade 2/5 1-3 horas Facilidade para iniciantes 65/100
github/copilot-sdk#2779 ·
Mantenedores costumam responder em até 8 dias
Todas as issues de github/copilot-sdk
Issues semelhantes
-
Dificuldade 1/5 Menos de uma hora Facilidade para iniciantes 75/100
521xueweihan/HelloGitHub#4105 ·
-
bug
Dificuldade 2/5 1-3 horas Facilidade para iniciantes 70/100
Mantenedores costumam responder em até 1 dia
-
code-maintenance
Dificuldade 2/5 1-3 horas Facilidade para iniciantes 80/100
Mantenedores costumam responder em até 1 dia
-
Dificuldade 1/5 Menos de uma hora Facilidade para iniciantes 85/100
Mantenedores costumam responder em até 1 dia
-
Dificuldade 2/5 1-3 horas Facilidade para iniciantes 78/100
krizaka/krizaka-notifications#32 ·
Mantenedores costumam responder em até 1 dia