Dá para enfileirar slash commands no Claude Code?

Resposta curta: não. O Claude Code 2.1.233 não tem fila de slash command, e digitar /code-review /clear /simplify numa linha só não roda três comandos. Ele roda o primeiro e entrega o resto a ele como texto puro. Medimos seis casos em 16 de agosto de 2026, e a falha tem dois formatos diferentes conforme qual comando vem primeiro. Um comando customizado único consegue ser dono de uma sequência, e invocações separadas dão algo perto de um recomeço limpo, com uma ressalva que só apareceu porque erramos.

Dá para enfileirar slash commands no Claude Code?

Dentro da sessão, não. O Claude Code trata o primeiro slash command da linha como o comando e tudo o que vem depois como argumento dele, então a fila nunca se forma. Testamos isso no Claude Code versão 2.1.233 em 16 de agosto de 2026, com dois comandos customizados descartáveis dentro de .claude/commands/: o echoargs, que responde com os argumentos que recebeu, e o marker, que responde com uma string fixa. Cada execução abaixo foi repetida em bash, zsh e sh.

Procurar por uma opção de fila ou de sequência na saída de ajuda do CLI do Claude Code não devolve ocorrência nenhuma. Uma busca propositalmente mais larga, por queue, sequence, chain e batch, devolve duas linhas, e as duas são a palavra chain dentro de keychain, e não a palavra sozinha. Casando palavra inteira, as duas buscas devolvem zero, então isto é ausência de recurso, e não uma sintaxe que deixamos de achar.

O que acontece quando você põe dois slash commands na mesma linha?

O primeiro comando roda e recebe o resto como string de argumento. No Claude Code, um arquivo de comando customizado em .claude/commands/ pode conter o marcador $ARGUMENTS, que se expande para o que a pessoa digitou depois do nome do comando. É esse mecanismo que absorve o seu segundo comando em silêncio: o interpretador já decidiu qual é o comando, então /marker deixou de ser comando e passou a ser uma string de sete caracteres sendo repassada.

Isso é fácil de não perceber porque nada falha. Não há erro, não há aviso e não há mensagem dizendo que um comando foi ignorado. O nosso comando echoargs existe justamente para tornar o invisível visível: ele imprime os próprios argumentos de volta, então ARGS=[/marker] é o interpretador mostrando o serviço. Sem um comando que ecoe argumentos, a mesma execução produziria apenas uma resposta plausível ao primeiro comando, e você nunca saberia que o segundo evaporou.

Um desenvolvedor do r/ClaudeCode descreveu esse mecanismo corretamente numa thread publicada em 16 de agosto de 2026, escrevendo que "you can't queue them on one line. the cli runs the first slash command and passes everything after it to that command as $ARGUMENTS", ou seja, que não dá para enfileirar numa linha porque o CLI roda o primeiro e passa todo o resto como argumento. Outro comentarista da mesma thread disse o contrário, que dá para enfileirar e que ele faz isso sempre. A nossa medição concorda com o primeiro e contradiz o segundo, e é por isso que esta pergunta merece medição em vez de enquete: as duas respostas estavam lado a lado, sem nada que as separasse.

Quebrar a linha entre os comandos ajuda?

Não. Enviar /echoargs e /marker separados por uma quebra de linha devolve ARGS=[/marker], exatamente o mesmo resultado de colocá los na mesma linha. A quebra é lida como parte de uma entrada única e não como um segundo envio, então o segundo comando é absorvido como texto de argumento de novo. Essa é a checagem número quatro do script, então ela é reproduzível em vez de afirmada.

Isso importa porque a quebra de linha é a primeira coisa que quase todo mundo tenta depois de a linha única falhar. Parece que deveria funcionar: num terminal, apertar enter costuma significar enviar. No Claude Code a entrada é um bloco, e o bloco é interpretado uma vez só. Saber disso poupa a segunda rodada de chute, e elimina a solução alternativa mais comum antes que alguém crie o hábito de usá la.

Existe um formato parecido que não testamos e sobre o qual não vamos afirmar nada, que é um here document ou um arquivo despejado no modo não interativo com vários comandos dentro. A nossa medição cobre texto enviado como uma entrada só, tendo ela quebra de linha ou não.

Por que um comando embutido como o /clear se comporta diferente?

Porque comando embutido consome a rodada em vez de repassar texto. Quando rodamos /clear /marker no Claude Code 2.1.233, a saída foi vazia. Não deu erro, não veio marcador, não veio nada. O /clear fez o trabalho dele de limpar a sessão e o texto depois dele não produziu resultado visível, que é um terceiro desfecho, diferente tanto de rodar quanto de ser ecoado.

Isso importa justamente para a sequência que as pessoas querem montar. O pedido que originou esta medição era uma corrente de fases de revisão separadas por /clear, no formato /code-review, depois /clear, depois /simplify. Essa corrente esbarra nos dois modos de falha ao mesmo tempo. Onde um comando customizado lidera, o /clear seguinte é engolido como argumento e o contexto nunca é limpo de verdade. Onde o /clear lidera, o que vem depois desaparece. Uma corrente feita dos dois tipos de comando falha de jeitos diferentes em posições diferentes, o que explica como dois desenvolvedores conseguem ter crenças opostas sobre o assunto: conforme o que cada um encadeou, um viu uma resposta plausível e o outro não viu nada.

A lição prática é que falha silenciosa aqui é pior que falha barulhenta. Se o Claude Code recusasse o segundo comando com uma mensagem, ninguém montaria pipeline de revisão em cima disso. Como o primeiro comando responde normalmente, a corrente pode parecer que funcionou por semanas.

Como rodar uma sequência de fases no Claude Code?

Escreva um comando customizado único que seja dono da sequência inteira. Criamos um comando pipeline em .claude/commands/ cujo corpo lista duas fases em ordem e pede o resultado de cada uma em sua própria linha. Rodar /pipeline devolveu PHASE_ONE_DONE PHASE_TWO_DONE, nessa ordem, em todas as nossas execuções em bash, zsh e sh. A sequência funciona quando um comando só responde por ela, porque aí a ordenação mora dentro do prompt e não dentro do interpretador.

Essa é a mesma saída que o comentarista do r/ClaudeCode propôs, e a nossa medição a sustenta. Ela carrega também uma limitação que vale declarar antes de você construir em cima: fase dentro de um comando não é contexto novo. Tudo o que a fase um leu e escreveu continua na conversa quando a fase dois começa, então, se o motivo de você querer o /clear entre as fases era impedir que a fase dois herdasse as suposições da fase um, um comando orquestrador não te dá isso. Ele dá ordenação, não isolamento.

Se ordenação é tudo de que você precisa, este é o formato mais barato e ele fica dentro de uma sessão só. Se você precisa que cada fase comece limpa, um comando único não entrega isso e invocações separadas chegam mais perto, embora não tão perto quanto acreditávamos no começo.

Invocação separada começa mesmo do zero?

Quase sempre, e a exceção é a coisa mais útil que medimos. A conversa realmente não atravessa: uma invocação foi instruída a lembrar da palavra BANANA42 e respondeu OK, e uma segunda invocação, no mesmo diretório, perguntada sobre qual palavra tinha acabado de receber, respondeu NO_MEMORY. Vimos isso em três execuções seguidas, em bash, zsh e sh, e foi com base nisso que escrevemos a versão confiante deste artigo.

Aí a quarta execução respondeu BANANA42, e a versão confiante estava errada. O Claude Code pode manter uma memória em ARQUIVO indexada pelo diretório de trabalho, guardada em .claude/projects, com um índice e um arquivo por fato. A execução que quebrou a nossa checagem tinha gravado a palavra nessa memória por conta própria, com carimbo de hora, e a invocação seguinte leu de volta. Dos doze diretórios de teste criados durante este trabalho, exatamente um terminou com a palavra guardada, e foi a execução que quebrou o resultado. Gravar a memória é decisão do agente, não uma opção que ligamos, e um caso em doze é fino demais para virar taxa publicada.

Ou seja, o NO_MEMORY nunca provou que a memória não existia. Provou apenas que nada tinha sido gravado daquela vez. Para tornar o mecanismo reproduzível em vez de acidental, a última checagem do script planta um arquivo de memória para o diretório de trabalho e pede a uma invocação nova que o leia. Ela voltou com MELANCIA99 em nove das nossas dez tentativas, e a única falha veio numa execução em que a checagem anterior já tinha escrito naquela mesma pasta de memória. A regra prática que sobrevive a tudo isso: se as suas fases não podem se contaminar, invocação separada é necessária e não suficiente, então confira se existe diretório de memória para aquele caminho antes de confiar no isolamento.

Como conferir o comportamento do interpretador?

O script que produziu todos os números deste artigo está impresso em duas partes, e a parte abaixo traz as quatro checagens do interpretador. Ela cria um diretório de trabalho descartável, escreve os três comandos customizados lá dentro e roda as checagens que dizem respeito a como a entrada é interpretada. Ela fixa um modelo pequeno por padrão para o custo ficar baixo, e você troca isso pela variável MODEL. Copie esta parte e a parte da memória para um arquivo só, nessa ordem, e rode. As duas partes terminam e começam numa linha de comentário, então nada quebra se a emenda perder a quebra de linha. O script é idêntico nas versões em português, inglês e espanhol deste artigo, com os comentários e os marcadores deixados em inglês de propósito, porque é código executável e mudar os marcadores mudaria a saída que as checagens comparam.

#!/usr/bin/env bash
# Does Claude Code run a queue of slash commands? Six checks.
set -uo pipefail
MODEL="${MODEL:-claude-haiku-4-5-20251001}"

lab=$(mktemp -d) || { echo "no temp dir"; exit 1; }
trap 'rm -rf "$lab"' EXIT
mkdir -p "$lab/.claude/commands"
printf -- '---\ndescription: echo\n---\nReply with exactly: ARGS=[$ARGUMENTS]\n' \
  > "$lab/.claude/commands/echoargs.md"
printf -- '---\ndescription: marker\n---\nReply with exactly: MARKER_TWO_RAN\n' \
  > "$lab/.claude/commands/marker.md"
printf -- '---\ndescription: two phases\n---\nDo both phases in order, one per line:\nPhase 1: reply PHASE_ONE_DONE\nPhase 2: reply PHASE_TWO_DONE\n' \
  > "$lab/.claude/commands/pipeline.md"

# Match only the markers, because a model may wrap them in extra prose.
run() {
  (cd "$lab" && claude -p "$1" --model "$MODEL" < /dev/null 2>/dev/null) \
    | grep -oE 'ARGS=\[[^]]*\]|MARKER_TWO_RAN|PHASE_[A-Z]+_DONE|NO_MEMORY|BANANA42|MELANCIA99' \
    | tr '\n' ' '
}

echo "version: $(claude --version)"
echo "1 two commands one line : $(run '/echoargs /marker')"
echo "2 built-in /clear first : [$(run '/clear /marker')]"
echo "3 one command, 2 phases : $(run '/pipeline')"
echo "4 separated by newline  : $(run '/echoargs
/marker')"
# ---- the memory checks continue below ----

A linha do grep está ali por causa de uma coisa que encontramos testando: numa das execuções o modelo embrulhou um marcador numa frase extra de explicação, o que fez a saída bruta variar entre execuções mesmo com a resposta sendo a mesma. Casar apenas os marcadores mantém os quatro resultados comparáveis de uma execução para a outra.

Como conferir o comportamento da memória?

As duas checagens de memória continuam o mesmo script, e elas precisam de um aviso que as checagens do interpretador não precisam. Elas criam, e depois apagam, uma pasta dentro do seu próprio .claude/projects, porque é lá que a memória plantada precisa morar para a última checagem significar alguma coisa. Só é apagada a pasta correspondente ao diretório temporário que o próprio script criou. Antes de montar esse caminho de remoção, o script se recusa a continuar se o caminho resolvido não tiver cara de chave profunda e se o seu HOME não estiver definido, e arma a limpeza antes de criar qualquer coisa, para que uma interrupção no meio não deixe a pasta plantada para trás.

# ---- memory checks ----
run 'Remember the word BANANA42. Reply only OK.' > /dev/null
echo "5 next run remembers?   : $(run 'Which word did I just tell you? If unknown, reply NO_MEMORY.')"

# Check 5 is not reliable on its own, and check 6 says why: Claude Code can
# keep a FILE memory keyed to the working directory, and that does survive a
# new invocation. We plant one and ask a fresh run to read it.
enc=$(printf '%s' "$(cd "$lab" && pwd -P)" | tr '/.' '--')
# Refuse to build a delete path from a value that is not a deep path key.
# An unreadable $lab makes enc empty, which would point the cleanup at the whole
# projects directory; a shallow value like a single dash would point it at a real
# folder that is not ours. Require at least three separators, and a real HOME.
case "$enc" in
  -*-*-*) : ;;
  *) echo "refusing to continue: could not resolve the lab path"; exit 1 ;;
esac
[ -n "${HOME:-}" ] || { echo "refusing to continue: HOME is not set"; exit 1; }
proj="$HOME/.claude/projects/$enc"
mem="$proj/memory"
# Arm the wider cleanup BEFORE creating anything, so a Ctrl-C in between
# cannot leave the planted folder behind.
trap 'rm -rf "$lab" "$proj"' EXIT
mkdir -p "$mem" || { echo "could not create the memory folder"; exit 1; }
printf -- '---\nname: planted\ndescription: word planted by this check\nmetadata:\n  type: reference\n---\n\nMELANCIA99\n' \
  > "$mem/planted.md"
printf -- '- [MELANCIA99](planted.md) - planted word\n' > "$mem/MEMORY.md"
echo "6 file memory crosses?  : $(run 'What is the planted secret word? If you do not know, reply NO_MEMORY.')"

Aquela recusa é uma cicatriz, e ela cresceu em duas etapas, que é a parte que vale copiar para qualquer coisa que você escreva que apague por caminho calculado. O primeiro rascunho montava o alvo da remoção expandindo uma variável sem conferi la, então um diretório ilegível deixava a variável vazia e apontava a limpeza para a pasta de projetos inteira. Acrescentamos uma checagem de que o valor começa com um separador, depois atacamos essa checagem e ela ainda estava frouxa: um separador sozinho passaria, e existe uma pasta com exatamente esse nome numa instalação real. Exigir uma chave profunda fecha os dois casos, e cada etapa foi confirmada forçando a falha e vendo o script abortar com a pasta de projetos intacta.

O que esta medição não cobre?

Ela cobre uma versão em uma máquina, e as partes com mais chance de envelhecer estão nomeadas para você reconferir. Tudo aqui foi medido no Claude Code 2.1.233, em macOS, em 16 de agosto de 2026. O registro do npm lista doze versões do Claude Code publicadas entre 3 e 14 de agosto de 2026, o que significa que o comportamento de interpretação descrito aqui é um fato de prazo curto, não uma propriedade permanente da ferramenta. Se você está lendo isto meses depois, rode o script você mesmo: seis checagens, uns poucos minutos, e você tem a resposta para a versão que está de fato instalada aí.

Três limites além da versão. Testamos o modo não interativo, claude -p, porque é o modo que um script consegue dirigir e conferir; a sessão interativa pode aceitar entrada de outro jeito, e nós não a medimos. Testamos com dois comandos customizados e um embutido, e não com o conjunto inteiro de comandos embutidos, então é possível que algum embutido se comporte de um quarto jeito que não vimos. E sobre a memória em arquivo, estabelecemos que ela existe, que sobrevive a uma invocação nova e que o agente às vezes a grava sem ser pedido, mas nem gravar nem ler se mostrou totalmente determinístico nas nossas execuções, e não mapeamos o que decide cada um dos dois.

Mais uma coisa que vale dizer sem rodeio, já que vendemos uma ferramenta nessa área. O CanvasCode, o nosso app de Mac que roda as CLIs oficiais de agente lado a lado num canvas só, não acrescenta fila de slash command ao Claude Code e nem poderia, porque a interpretação acontece dentro do CLI. O que rodar vários agentes lado a lado muda é que fases que não dependem uma da outra podem rodar ao mesmo tempo em vez de em fila, o que é um problema diferente do que este artigo mede.