- O Claude Code
2.1.198 ativou por padrão um recurso de avanço automático que, se não houvesse resposta por 60 segundos em AskUserQuestion, fazia o modelo continuar a tarefa com base no próprio julgamento, mas isso não foi registrado no changelog nem na documentação no lançamento
- Ele não aprovava automaticamente solicitações de permissão, mas, em ambientes com ferramentas já permitidas ou com
--dangerously-skip-permissions, podia passar no lugar do usuário por gates de decisão como “staging ou production”; mesmo que apenas algumas respostas fossem inseridas, o modelo escolhia o restante
- Cerca de dois dias após a denúncia do problema, a versão
2.1.200 não removeu o recurso, apenas o desativou por padrão, convertendo-o para um modelo opt-in em que se escolhe uma das opções 60s, 5m, 10m ou never em /config
- Embora o repositório público não contenha o código-fonte real do produto nem os commits de introdução/reversão, a comparação dos bundles JavaScript incluídos no executável Bun do npm confirma que strings AFK, schemas e eventos de análise foram adicionados juntos na
2.1.198
- Quando atualizações automáticas padrão se combinam com registros de mudanças incompletos, pressupostos de segurança podem mudar sem intervenção do usuário. Para fixar a CLI enquanto atualiza os plugins, é preciso definir
DISABLE_AUTOUPDATER=1 e FORCE_AUTOUPDATE_PLUGINS=1 em conjunto
A 2.1.198, que decidiu no lugar da pessoa após 60 segundos
- O Claude Code
2.1.198, lançado em 1º de julho de 2026, desbloqueava AskUserQuestion depois de 60 segundos aguardando uma resposta humana e instruía o modelo a seguir com a melhor decisão com base no contexto
- A saída exibia
No response after 60s — continued without an answer
- Havia também um aviso de que era possível perguntar novamente, mas a mesma expiração de tempo se aplicava à nova pergunta
- Se o usuário respondesse apenas parte das perguntas e se ausentasse, a entrada não era descartada; eram enviadas respostas parciais
- Se, entre três perguntas, apenas a primeira fosse respondida, a tarefa continuava com essa resposta e com as demais escolhidas pelo modelo
- A mensagem na tela escolhia entre
continued with the answers selected so far ou continued without an answer, dependendo de haver respostas ou não
- Não é que não houvesse absolutamente nenhum countdown na tela
- Ao pressionar uma tecla, o timer reiniciava e aparecia uma mensagem como
auto-continue in 12s · any key to stay
- Porém, como o valor padrão de
CLAUDE_AFK_COUNTDOWN_MS era 20 segundos, durante os primeiros 40 segundos parecia uma pergunta bloqueante comum, e o alerta só era exibido nos últimos 20 segundos
- Usuários executando vários agentes em abas diferentes ou que tivessem se ausentado poderiam não ver o alerta
Escopo de aplicação e limites dos gates de segurança
- O timeout se aplicava apenas a
AskUserQuestion e não era conectado a aprovações de plano nem a prompts de permissão como Do you want to allow …
- No executável, o componente de countdown e o hook de timer estavam conectados apenas à caixa de diálogo de perguntas
- A referência de ferramentas também afirma que prompts de permissão não são resolvidos automaticamente em estado ocioso
- Em modos de execução nos quais o prompt de permissão nem chegava a aparecer, essa separação não funcionava como proteção
- Era possível usar
bypassPermissions, acceptEdits, allowedTools, --dangerously-skip-permissions e hooks PreToolUse
- Se um comando de deploy estivesse na lista de permissões ou a verificação de permissão fosse contornada, escolhas de
AskUserQuestion como “staging ou production?” ou “qual config?” poderiam ser o único gate restante
- O timer não concedia permissões, mas podia deixar a própria escolha de uma tarefa já autorizada a cargo do modelo
- O schema da ferramenta não tinha uma entrada
timeout, e o modelo não podia defini-la nem controlá-la
- Os parâmetros de entrada eram apenas
questions, answers, annotations e metadata
- Quem pulava a resposta não era o modelo, mas o harness do agente, que retornava a resposta automaticamente
Cronologia de lançamento e reversão
- Os registros públicos confirmados seguem esta ordem
- 2026-06-29: lançamento da
2.1.196, estimada pelo relator como a última versão normal
- 2026-06-30: lançamento da
2.1.197, com changelog contendo apenas uma linha sobre o lançamento do Sonnet 5
- 2026-07-01: lançamento da
2.1.198, com o avanço automático
- 2026-07-02 02:54 UTC: Aleksey Nogin abriu a issue #73125
- 2026-07-02 03:45 UTC: foi compartilhada nos comentários a saída não documentada
CLAUDE_AFK_TIMEOUT_MS
- 2026-07-02: com a issue ainda aberta, foi lançada a
2.1.199 com 24 itens, mas o avanço automático continuou sem menção
- 2026-07-03: na
2.1.200, o comportamento padrão foi revertido
- 2026-07-04 18:04 UTC: a issue foi encerrada
- A issue recebeu 384 👍 e 143 comentários, e o ambiente relatado era
2.1.198, Opus, AWS Bedrock e terminal do VS Code
- Foram cerca de dois dias entre o relato do problema e a mudança do padrão
Como a 2.1.200 corrigiu o problema
- A
2.1.200 não removeu o recurso; ela desativou por padrão o avanço automático e o transformou em opt-in via /config
- Antes da correção, a
2.1.198 não tinha a configuração askUserQuestionTimeout em /config, e, para evitar o impacto, era preciso usar uma variável de ambiente que não aparecia na documentação de lançamento
- Na
2.1.211, a implementação completa continua presente
- O nome do item em
/config é Question auto-continue timeout
- Os valores permitidos são
60s, 5m, 10m, never
- Se não configurado, é tratado como
never, deixando o recurso desligado
- O timeout interno padrão ainda é 60.000 ms, e o limite do countdown é 20.000 ms
CLAUDE_AFK_TIMEOUT_MS e CLAUDE_AFK_COUNTDOWN_MS podem sobrescrever os valores configurados
- A correção não removeu o timer; ela apenas adicionou uma condição de gate para ativá-lo somente quando houver uma configuração ou variável de ambiente
- Usuários fixados em versões afetadas podiam contornar temporariamente o problema definindo um valor muito alto para
CLAUDE_AFK_TIMEOUT_MS em settings.json
Introdução de um recurso que ficou fora do changelog
- As notas de versão foram publicadas com o mesmo conteúdo no changelog oficial e no
CHANGELOG.md do repositório
- Considerando os registros da época com base em um commit fixo, a adição do avanço automático não aparece em nenhuma versão
2.1.197: uma linha sobre o lançamento do Sonnet 52.1.198: cerca de 30 itens, mas sem avanço automático2.1.199: também ausente nos 24 itens publicados depois da abertura da issue
AskUserQuestion era uma ferramenta que normalmente aparecia no changelog, tendo sido mencionada 15 vezes ao todo em 13 versões após a 2.0.55
- Mas, no intervalo em que a mudança entrou, de
2.1.181 até antes da 2.1.200, ela não aparece nenhuma vez
- Das duas mudanças de comportamento, ativar e desativar, apenas a desativação foi registrada
- O único item que registrou o avanço automático pela primeira vez foi a frase da
2.1.200 dizendo que ele “por padrão não avança mais automaticamente e pode ser ativado via /config”
CLAUDE_AFK_TIMEOUT_MS não aparecia em nenhum lugar do changelog nem do README
Documentação adicionada depois da reversão do comportamento
- A referência atual de variáveis de ambiente registra as duas variáveis de ambiente AFK e afirma explicitamente que o avanço automático em 60 segundos foi ativado por padrão nas versões
2.1.198 e 2.1.199
- Esse documento não pode representar o estado da documentação no dia do lançamento
- O
askUserQuestionTimeout indicado pelo texto atual não existe no executável da 2.1.198
- Nas capturas do Wayback Machine de 23 de junho e de 1º de julho às 12:11 e 21:35 UTC,
CLAUDE_AFK e AskUserQuestion apareciam 0 vezes cada
- O item de comparação
DISABLE_AUTOUPDATER foi confirmado 2 vezes em todas as capturas, portanto a ausência não se devia a falha na coleta da página
- A
2.1.198 foi publicada no npm em 1º de julho às 16:50:16 UTC, mas mesmo na documentação de 4 horas e 45 minutos depois não havia AFK, avanço automático, ferramenta de perguntas nem contagem regressiva
- O texto relacionado foi adicionado entre 1º de julho às 21:35 e 5 de julho às 13:58, intervalo que também inclui a reversão na
2.1.200
- A nova documentação registrou apenas o estado posterior à correção, já “desativado por padrão”, de modo que em nenhum momento o comportamento padrão real de 1º e 2 de julho foi documentado
Código-fonte do produto e commits ausentes do repositório público
- Não há commit público que introduza o recurso nem commit público que o reverta
- No histórico público do Git, restam apenas dois commits automáticos que atualizaram o changelog e o
feed.xml
75709ea: publicação das notas de versão da 2.1.1981322e9b: publicação das notas de versão da 2.1.200
- O repositório
anthropics/claude-code tem 216 arquivos rastreados, dos quais 104 são Markdown, e não contém o código-fonte real do produto distribuído
- Os arquivos executáveis são exemplos ou scripts de automação para rastreamento de issues
plugins/ e examples/ também contêm plugins de exemplo, configuração Terraform para gateway GCP, perfis MDM etc.
- A diferença entre as tags
2.1.197 e 2.1.198 é apenas o CHANGELOG.md e o feed.xml, que repete o conteúdo em RSS
- Nas dez versões consecutivas de
2.1.196 a 2.1.206, também só esses dois arquivos mudaram
- As tags não são releases de código-fonte; na prática, são tags de notas de versão
- Não é possível verificar o comportamento realmente distribuído por meio do changelog nem por comparação do repositório ou das tags; o código escrito não foi aberto ao público e é distribuído apenas como executável compilado
Indícios de projeto e instrumentação deliberados
- Não há documentação oficial de design, PR nem texto de changelog que permita confirmar o motivo da introdução
- Os nomes e mensagens são evidências circunstanciais de que o recurso mirava situações em que agentes paralelos ficavam bloqueados indefinidamente por causa de uma pessoa ausente
- O nome interno
AFK significa away from keyboard
- A mensagem pressupõe que “o usuário pode estar longe do teclado”
- Participantes da issue disseram usar fluxos de trabalho em que dezenas de agentes aguardam respostas humanas por dias
- Na
2.1.198, um campo afkTimeoutMs, que indica se houve resolução automática, foi adicionado ao esquema de resultado da ferramenta
- Ele não existe no caminho em que uma pessoa responde e registra o tempo de inatividade quando há resolução automática
- É usado para informar ao modelo que a resposta foi resolvida automaticamente e para escolher componentes da saída no terminal
- Na mesma versão, também foi adicionado o evento de análise
tengu_ask_user_question_afk_auto_advance
- Ele envia
timeoutMs, número de perguntas, se estava no modo plano e se havia respostas parciais
- Não envia o texto original da pergunta; usa
source_hash e contadores
- Como
hadPartialAnswers foi instrumentado separadamente, o caminho de respostas parciais também tinha código e medição próprios
- Como o comportamento, a interface de contagem regressiva, o campo de esquema e o evento de análise entraram juntos em uma versão, não se tratava de uma linha acidental, mas de um recurso com sistema de medição
- Só com essas evidências não é possível saber quem escreveu, revisou, aprovou ou fez o merge, nem em que etapa uma pessoa interveio
Um executável Bun de código fechado, mas legível
- O Claude Code instalado é um executável nativo de cerca de 250 MB sem símbolos removidos
- O formato de executável único do Bun anexa o grafo de módulos depois do runtime, e no executável do Claude Code também é possível encontrar o marcador
---- Bun! ----
- Como o Bun inclui o bundle JavaScript dentro do executável, é possível ler com
strings nomes de configurações, mensagens, eventos de análise etc.
- O diretório de instalação local mantém apenas algumas versões recentes, mas o npm conserva os executáveis por plataforma de cada versão
@anthropic-ai/claude-code é um stub de instalação de cerca de 152 KB- O pacote real da
2.1.198 para Linux x64 tem cerca de 249 MB
- Embora não haja código-fonte público, é possível baixar os artefatos de cada release e verificar o comportamento distribuído, portanto não é uma caixa-preta completa
Comparação dos executáveis 2.1.197 e 2.1.198
- Ao procurar strings relacionadas a AFK nos dois executáveis, a fronteira fica clara
2.1.197: away from keyboard, CLAUDE_AFK_TIMEOUT_MS, CLAUDE_AFK_COUNTDOWN_MS aparecem 0 vezes2.1.198: aparecem 2, 3 e 3 vezes, respectivamente
- Após a correção, no gate do temporizador da
2.1.211 foi adicionada a condição de que deve existir um valor em /config ou uma variável de ambiente
- A
2.1.198 também já tinha um gate que verificava, por exemplo, se havia uma execução concorrente externa
- Porém não havia uma condição que o usuário pudesse desativar, e a correção foi no formato de acrescentar mais uma condição com
&&
- Comparar releases comuns sem saber o nome do recurso nem a versão em que o problema ocorreu é muito mais difícil
- Em uma comparação simples com base em
strings -n 8, 21.903 strings diferiam
- Dependendo do tamanho mínimo das strings, isso pode mudar para 81.289 ou 29.910, portanto 21.903 não é uma característica fixa do release
- A cada build, o minificador muda nomes de identificadores, então a maior parte é ruído, não mudanças reais de funcionalidade
- Ao filtrar, entre as strings adicionadas, apenas frases em inglês que começam com letra maiúscula, têm formato de frase comum e pelo menos 5 palavras, o resultado cai para 156 linhas
- Entre elas está
Before going idle the user had selected:
- Como é a string inserida na conversa quando a caixa de diálogo responde no lugar de uma pessoa, mesmo sem informação prévia era uma mudança que justificava interromper a revisão
- Era possível encontrá-la em cerca de 5 minutos com
curl, strings e diff, mas exigir que usuários inspecionem o executável a cada release de atualização automática não substitui um changelog
Um problema de segurança maior que o custo
- A seleção automática de um caminho incorreto pode consumir tokens desnecessários
- O problema maior é que hooks e regras que pressupunham
AskUserQuestion como um gate de segurança bloqueante passam a funcionar com uma contagem regressiva de 60 segundos
- O Claude Code é usado também em ambientes perigosos, como deploys, infraestrutura e scripts próximos à produção
- Como o Claude Code faz atualização automática por padrão, combinada a uma mudança silenciosa de comportamento, as premissas de segurança existentes podem mudar sem que o usuário faça nada
- A discussão de que a política de receber imediatamente a versão mais recente pode ser, por si só, uma escolha arriscada se conecta a On Cooldowns and Dependabot Tuning
Como desativar atualizações e a ordem de prioridade
- Para determinar se as atualizações estão desativadas, as seguintes variáveis de ambiente são verificadas em ordem, e o primeiro valor correspondente é aplicado
DISABLE_UPDATES=1: bloqueia todos os caminhos de atualização, incluindo claude update manualDISABLE_AUTOUPDATER=1: interrompe apenas a verificação em segundo plano, permite atualização manual e tem prioridade sobre a configuração autoUpdatesCLAUDE_CODE_DISABLE_NONESSENTIAL_TRAFFIC=1: interrompe, em conjunto, atualizações automáticas, comando de feedback, relatório de erros e telemetria
- Colocar isso no bloco
env de ~/.claude/settings.json, em vez do perfil do shell, permite aplicar a todas as sessões, incluindo CI, cron, systemd e terminais de IDE
{
"env": {
"DISABLE_AUTOUPDATER": "1"
}
}
- O escopo de configuração fica mais forte nesta ordem: perfil do shell,
~/.claude/settings.json por usuário, .claude/settings.json por repositório e managed-settings.json para administração central
- Os caminhos de
managed-settings.json são os seguintes
- macOS:
/Library/Application Support/ClaudeCode/managed-settings.json
- Linux/WSL:
/etc/claude-code/managed-settings.json
- Windows:
C:\Program Files\ClaudeCode\managed-settings.json
- O caminho antigo
C:\ProgramData\ClaudeCode não é mais lido
- Não há flag de CLI para desativar atualizações automáticas, e
/doctor mostra o tipo de instalação e o canal de atualização
Ao desativar a atualização da CLI, os plugins também param
- Ao desativar o atualizador automático por qualquer método, seja variável de ambiente,
autoUpdates: false etc., as atualizações automáticas de plugins também são interrompidas
- A documentação de descoberta de plugins informa que, ao definir
FORCE_AUTOUPDATE_PLUGINS=1 junto com DISABLE_AUTOUPDATER, é possível fixar a CLI e continuar atualizando os plugins
- Por outro lado, a documentação de
/setup, que orienta como desativar atualizações automáticas de fato, e a tabela de variáveis de ambiente de configuração não mencionam o impacto sobre plugins nem FORCE_AUTOUPDATE_PLUGINS
- No executável, há quatro caminhos que fazem as atualizações de plugins pararem
DISABLE_UPDATESDISABLE_AUTOUPDATERCLAUDE_CODE_DISABLE_NONESSENTIAL_TRAFFICautoUpdates: false
- Durante a execução, em vez de um aviso de que os plugins pararam, resta apenas o log de debug
Plugin autoupdate: skipped (auto-updater disabled)
- A configuração para fixar a CLI e manter os plugins é a seguinte
{
"env": {
"DISABLE_AUTOUPDATER": "1",
"FORCE_AUTOUPDATE_PLUGINS": "1"
}
}
FORCE_AUTOUPDATE_PLUGINS, DISABLE_AUTOUPDATER e DISABLE_UPDATES interpretam 1, true, yes e on como verdadeiro, sem diferenciar maiúsculas de minúsculas, e tratam 0 como falsoCLAUDE_CODE_DISABLE_NONESSENTIAL_TRAFFIC verifica apenas a existência, não o valor; portanto =0 também a ativa e, nesse caso, tanto o atualizador automático quanto as atualizações de plugins param
Outras armadilhas nas configurações de atualização
- Mesmo que
CLAUDE_CODE_DISABLE_NONESSENTIAL_TRAFFIC seja usado por motivos de privacidade ou restrição de comunicação externa, a CLI e os plugins ficam fixados juntos
autoUpdates: false, que não está documentado, pode ser ignorado em instalações nativas quando autoUpdatesProtectedForNative está ativado
- As variáveis de ambiente são verificadas antes dessa configuração e aplicadas incondicionalmente
- A
2.1.98 corrigiu um problema em que, em instalações via npm, DISABLE_AUTOUPDATER não impedia completamente a verificação da versão no registro nem a modificação de links simbólicos
- Também foi corrigido o problema em que o atualizador automático sobrescrevia, a cada release, launchers personalizados ou links simbólicos de
~/.local/bin/claude; atualmente, /doctor mostra launchers gerenciados externamente
- Instalações nativas e via npm se atualizam automaticamente por padrão
- Homebrew, WinGet, apt, dnf e apk não são alvos de autoatualização por padrão
- Homebrew e WinGet podem aderir a isso com
CLAUDE_CODE_PACKAGE_MANAGER_AUTO_UPDATE=1
Problemas de confiança restantes no processo de release
- Quando uma pessoa supervisiona vários agentes ao mesmo tempo, é difícil verificar todas as perguntas em 60 segundos, e também não é possível saber de antemão quantos tokens ou quanto trabalho serão consumidos após uma escolha incorreta
- Não é possível confirmar por registros públicos quais pessoas e procedimentos a Anthropic envolveu nas etapas de criação, revisão, aprovação, merge, documentação e comparação de releases do recurso
- O recurso foi corrigido em cerca de dois dias para um formato adequado de opt-in, mas ficou claro que, por meio de um ciclo de releases diário e atualização automática por padrão, recursos inesperados podem ser distribuídos sem changelog
- A análise do executável é uma alternativa eficaz para verificar o que foi realmente distribuído, mas não substitui um changelog preciso e bem editado
- Não há base para presumir má-fé; o critério para avaliar o que melhorou nesse processo de release será se coisas do mesmo tipo se repetirem
1 comentários
Opiniões do Hacker News
Sou Thariq, da equipe do Claude Code, que criou o AskUserQuestion. À medida que o modelo ficou mais poderoso, recebemos feedback de que tarefas longas ficavam travadas em perguntas logo no início, então fizemos uma mudança para resolver isso, mas ela não atingiu o padrão de qualidade esperado e também não foi a forma normal de lançamento do Claude Code
Mesmo que as avaliações internas tenham sido boas, deveríamos tê-la oferecido como opt-in desde o início e registrado no changelog. O AskUserQuestion não foi projetado como um mecanismo de segurança, mas entendo que ele acabou assumindo esse papel para alguns usuários; vamos procurar outras formas de equilibrar tarefas longas e entrada do usuário, e aprender com esta implantação
Uma empresa do porte da Anthropic deveria reconhecer e corrigir não a falha de uma pessoa, mas a falha do PR e dos processos organizacionais que permitiram esse lançamento
Fico curioso se esse tipo de transparência é uma nova tendência da era da internet ou se a cultura das empresas de tecnologia está mudando
A frase “nem todos os recursos aparecem necessariamente no changelog” e o fato de a Anthropic não explicar por que não mantém mais o changelog como um histórico completo são especialmente frustrantes. Não dá para saber o que mais está sendo implantado às escondidas (1)
O que Boris Cherny fez nessa discussão foi apenas remover “extreme danger” do título da issue no GitHub (2). Ainda bem, pelo menos, que a Anthropic adicionou uma opção e a desativou por padrão, mas a OpenAI insiste em não permitir desativar o limite de 60 segundos (3). Ainda assim, a ferramenta de execução do Codex é mais open source, então os usuários podem fazer fork e adicionar opções por conta própria
Não vou confiar em uma ferramenta de execução criada por uma empresa que, quando acabar o subsídio do custo de tokens, passará a cobrar também pelo custo computacional. Hoje os interesses estão alinhados, mas no momento em que aumento de tokens significar aumento de lucro, os incentivos distorcidos serão grandes demais
No fim, é provável que ferramentas de execução open source vençam, então é melhor que as próprias empresas as tornem open source
Recentemente cliquei com o mouse para focar a janela do terminal, mas o Claude Code interpretou isso como um clique em uma opção, o que foi um transtorno
Passei por isso hoje. Eu estava lendo a resposta do agente quando apareceu uma pergunta, e antes mesmo de eu conseguir ler a pergunta ele selecionou algo automaticamente. Não sei para onde foi a engenharia de software
Cheguei a ver ele acrescentando uma flag de aprovação automática a
terraform apply, o que é muito perigosoNão entendo como o Claude Code parece configurar uma máquina virtual bastante pesada no computador, mas por padrão não faz praticamente nenhum isolamento por sandbox. Modelos recentes modificam o computador de forma agressiva; mesmo quando pedi para depurar código de UI de frontend, ele começou a reescrever arquivos do sistema Linux acessíveis com as permissões do usuário
Depois que coloquei em uma sandbox, ficou claro como eram frequentes as tentativas de sair dos limites por motivos triviais, e isso aumentou ainda mais os motivos para usar OpenCode e LLMs locais
Há muitas reações interpretando isso como má-fé, mas, na prática, parece mais próximo de a equipe de desenvolvimento ter criado uma funcionalidade que ela própria queria usar. É realmente muito frustrante deixar uma sessão do Claude rodando e, ao voltar, descobrir que ela ficou presa em uma única pergunta e não fez nada
Também não se deve acreditar que o fato de o Claude fazer perguntas seja o único mecanismo capaz de evitar um desastre. Os limites de segurança devem ser definidos nas permissões concedidas externamente, não no julgamento interno do Claude. Ao mesmo tempo, o texto contém frases como “Which cuts less far than it looks.”, e é provável que o Claude não tivesse parado para perguntar sobre isso
Pelo mesmo motivo de não pedir a um LLM para resolver palavras cruzadas no meu lugar, não publico prosa escrita por LLM, porque isso tira o prazer
Não acho que tenha sido malicioso, mas foi imprudente e descuidado, e não vejo a equipe demonstrando aprendizado mesmo quando coisas parecidas se repetem. O Claude Code não é uma ferramenta estável e confiável, mas algo mais próximo de um experimento de ponta, e esse é o preço a pagar ao escolhê-lo no lugar de outras ferramentas de execução
Não havia sequer parâmetros para o Claude indicar a gravidade da pergunta ou o tempo esperado de resposta, e o limite de tempo era de apenas 60 segundos. Eu ia verificar a documentação no segundo monitor para encontrar a resposta da pergunta e, antes de voltar, ela já tinha sido pulada; em 60 segundos é difícil até ler o contexto da pergunta
Mesmo que não tenha havido má-fé, isso revela uma grande lacuna de julgamento no processo de transformar a ideia em distribuição real
Um recurso parecido já tinha sido introduzido antes no plugin Codex para VS Code e foi removido rapidamente. É comum LLMs de diferentes provedores convergirem para ideias e vieses semelhantes, então fico curioso sobre a possibilidade de um LLM ter recomendado a mesma ideia ao gerente de produto ou responsável pelo Claude
AskUserQuestion não é um mecanismo de aprovação de permissões, então parece aceitável como comportamento padrão. Um recurso separado de alerta pode ser necessário, mas, quando o modelo ficar bom o suficiente, deixá-lo escolher e prosseguir por conta própria, com o usuário corrigindo depois, também facilita a gestão de múltiplos agentes
O fato de a Anthropic poder mudar integralmente o comportamento do Claude Code é um dos motivos pelos quais o agente de codificação Pi foi criado. Se o usuário investe bastante tempo construindo fluxos de trabalho em cima do produto, a consistência é muito importante