Agentes de código e Control Room

O MXterm Pro pode iniciar 27 agentes de código. A lista completa está na página Agentes. A tabela abaixo mostra alguns deles.

Escolha os agentes na lista Agentes de IA ao criar um espaço de trabalho, ou troque o agente de um painel depois, pelo ícone de agente à esquerda do cabeçalho dele. Um painel de agente executa o comando da tabela abaixo. Terminal não executa nenhum comando.

Para Claude Code, Codex, Gemini CLI, Cursor Agent, OpenCode e Grok, o MXterm Pro procura o executável no seu PATH e em pastas comuns de instalação (no macOS e no Linux, por exemplo /opt/homebrew/bin, ~/.local/bin e ~/.npm-global/bin) e marca o agente como Não instalado quando não encontra nada. O Gemini CLI também conta como instalado quando existe uma pasta ~/.gemini. Os outros agentes da tabela sempre aparecem na lista; se a CLI deles não estiver instalada, o shell do painel avisa que o comando não foi encontrado. Os agentes que não estão na tabela, como OpenClaw, OpenClaude, Hermes Agent, Devin CLI, Kimi Code, Aider, Cline, Goose, Crush, Kilo Code, Kiro CLI, Auggie, Autohand Code, Codebuff, Command Code e Continue, aparecem no Composer só depois que o MXterm Pro encontra a CLI deles. Configurações → Agentes mostra se cada agente está instalado; veja Configurações.

Ativar Bypass Mode (aprovar permissões da CLI automaticamente) vem desativado por padrão. Se você não mexer, todo agente pergunta antes de executar um comando ou editar um arquivo, exatamente como a CLI dele faria sozinha.

A caixa fica no Composer do espaço de trabalho, a tela que uma nova aba abre. A escolha é salva e vale para todo painel de agente iniciado depois, em qualquer espaço de trabalho. Agentes que já estão rodando mantêm as flags com que foram iniciados.

A flag é adicionada ou removida quando o painel inicia, então a caixa controla da mesma forma todos os agentes que usam flag. Além dos cinco acima, o MXterm Pro conhece uma flag para pular aprovações do OpenClaude, Hermes Agent, Devin CLI, Kimi Code, Aider, Crush, Kiro CLI, Autohand Code e Command Code, 14 agentes no total. O Goose não tem flag: o modo automático dele é uma variável de ambiente (GOOSE_MODE=auto) oferecida só nas Configurações. Os outros agentes, incluindo OpenCode, GitHub Copilot, Amp, Cursor Agent, Antigravity e OMP, iniciam com o comando simples de qualquer jeito; chutar uma flag para eles só faria a CLI se recusar a iniciar.

Para Claude Code, Codex, Gemini CLI, Cursor Agent e OpenCode, o MXterm Pro lê a tela do painel para saber o que o agente está fazendo. Ele mostra um indicador ao lado do painel na lista de terminais da barra lateral e na lista de membros da Control Room (antes War Room), e também na aba do espaço de trabalho, que exibe o indicador mais urgente entre os painéis dela. OMP, Grok e Qwen Code são lidos para uma coisa só: quando um deles mostra uma ferramenta esperando sua aprovação, o indicador fica vermelho. O MXterm Pro não tem regra para o estado de trabalho deles. O Gemini CLI é lido nos diálogos de aprovação, de plano, de pergunta e de confiança na pasta. O Goose também é lido, com regras que não foram verificadas em uma sessão real. No total, 9 dos agentes têm detecção de estado; os outros não mostram indicador.

• Vermelho: o agente está bloqueado e precisa de você.
• Amarelo: o agente está trabalhando. Outros painéis mostram o mesmo indicador amarelo enquanto imprimem saída.
• Verde: o agente terminou enquanto você não estava olhando para aquele painel. O indicador some quando você dá foco ao painel.

As configurações de notificação ficam em Configurações → Notificações, sob a chave geral Notificações de agentes. Três eventos podem notificar, cada um com sua própria chave, todas ativadas: Um agente terminar, Um agente precisar de você e Um agente parar inesperadamente. As mensagens da Control Room que continuam retidas (veja Enviar mensagens na Control Room) também geram um banner, Mensagens aguardando envio, sob a chave Um agente precisar de você.

Clicar em um banner leva você ao painel a que ele se refere. A janela vem para a frente, a aba certa abre, um painel escondido atrás de outro painel maximizado é restaurado, o painel recebe foco e rola até a saída mais recente. Se o painel tiver sido fechado nesse meio tempo, a janela ainda vem para a frente e nada mais acontece.

Algumas regras mantêm os banners discretos. Você nunca é notificado sobre o painel que está olhando. Um turno concluído em menos de 5 segundos ganha o indicador, mas nenhum banner nem aviso sonoro. Eventos que chegam juntos são agrupados e entregues como um único aviso sonoro e um único banner. E no macOS, olhar para um painel retira os banners dele da Central de Notificações.

O MXterm Pro executa um servidor MCP em 127.0.0.1 com uma porta aleatória e define estas variáveis de ambiente em todo painel: MXTERM_MCP_URL, o endereço do servidor, e MXTERM_SESSION, um token exclusivo daquele painel, além dos nomes antigos SWARMTERM_MCP_URL e SWARMTERM_SESSION com os mesmos valores, que são os que as entradas de configuração dos agentes abaixo leem. Os agentes usam o servidor para abrir uma prévia web ao lado do painel, para conversar na Control Room e, em espaços de trabalho com isolamento por worktree, para criar e remover worktrees.

As ferramentas se chamam mxt_room.*. As versões anteriores à 1.1.43 as chamavam de war_room.*; esses nomes continuam funcionando por enquanto.

Claude Code, Codex e OMP são conectados automaticamente, e o Gemini CLI quando o painel dele inicia. A cada inicialização, o MXterm Pro confere estes arquivos e grava as entradas quando estão ausentes ou desatualizadas, estando os agentes instalados ou não:

• ~/.claude.json (ou $CLAUDE_CONFIG_DIR/.claude.json): uma entrada mxterm em mcpServers que lê a URL e o token do ambiente do painel. Ao gravar essa entrada, ele também acrescenta "crossSessionInbound": "accept" se a chave não estiver definida.
• ~/.codex/config.toml (ou $CODEX_HOME/config.toml): uma tabela [mcp_servers.mxterm] com a URL atual do servidor e sem token: cada painel do Codex que o MXterm Pro inicia envia o seu, então vários painéis do Codex podem entrar em uma sala. A URL é reescrita a cada inicialização porque a porta muda.
• ~/.omp/agent/mcp.json: uma entrada mxterm em mcpServers que lê a URL e o token do ambiente do painel, igual à do Claude Code, mais uma linha $schema se o arquivo não tiver nenhuma.
• ~/.zshrc, só se o arquivo existir e ainda não mencionar SWARMTERM_SESSION: a linha export SWARMTERM_SESSION="${SWARMTERM_SESSION:-global}" é acrescentada no final.

O Gemini CLI não consegue ler variáveis de ambiente nas configurações de MCP, então a configuração dele é diferente. Cada vez que um painel do Gemini CLI inicia em uma pasta, o MXterm Pro grava <folder>/.gemini/settings.json com o endereço do servidor e o token do próprio painel em texto puro, e adiciona .gemini/settings.json ao .gitignore da pasta, criando o arquivo se ele não existir. O Grok lê a entrada mxterm em ~/.claude.json, então o MXterm Pro não grava mais nada para ele. Configurações → Agentes mostra quais agentes o MXterm Pro considera configurados.

Os outros agentes não são configurados automaticamente, e não foi verificado se eles reconhecem as ferramentas do MXterm Pro. Se um agente não mostrar nenhuma, adicione um servidor MCP HTTP com a URL $MXTERM_MCP_URL e o cabeçalho Authorization: Bearer $MXTERM_SESSION. Leia os dois do ambiente em vez de copiar os valores, porque a porta muda a cada inicialização e o token é diferente em cada painel.

Marque Isolar funcionalidades em git worktrees no Composer do espaço de trabalho para dar a cada painel de agente o próprio worktree e o próprio branch. Vem desativado por padrão e vale só para o espaço de trabalho que você está criando.

• Cada painel de agente recebe um branch como swarm/brave-otter e um worktree em <folder>/.worktrees/swarm-brave-otter. O nome do branch aparece no cabeçalho do painel.
• Painéis Terminal simples ficam na própria pasta. O mesmo vale para um painel de agente cujo worktree não pôde ser criado.
• Os worktrees partem do commit HEAD atual. Alterações não commitadas e arquivos ignorados, como node_modules, não são copiados, então instale as dependências em cada worktree.
• O MXterm Pro adiciona .worktrees/ ao .gitignore da pasta, criando o arquivo se for preciso, e não faz commit dessa alteração.
• Os agentes do espaço de trabalho podem chamar as ferramentas MCP worktree.spawn, worktree.list e worktree.remove.

Para remover worktrees quando terminar de usá-los, abra a aba Git do painel direito e clique em Limpar worktrees… ao lado da lista de worktrees.

1. Entradas cujo diretório não existe mais são removidas na hora, sem confirmação.
2. As demais abrem em Limpar worktrees. Worktrees sem arquivos não commitados só são contados ("N worktrees serão removidos (diretório e branch).") e são removidos quando você confirma.
3. Worktrees com trabalho dentro aparecem separados, em Estes têm trabalho não salvo: marque para remover mesmo assim:, cada um com o número de arquivos não commitados e de commits não mesclados. Eles não vêm marcados.
4. Limpar worktree (ou Limpar N worktrees) remove cada diretório e exclui o branch dele. Um painel que ainda esteja rodando em um deles é movido para fora antes.

Os worktrees que o MXterm criou também aparecem, com tamanho e idade, em Configurações → Agentes (veja Configurações); esse cartão só remove uma pasta quando você clica em Remover e sempre mantém o branch. Você ainda pode fazer isso à mão com git worktree list, git worktree remove e git branch -d a partir da pasta. Um agente também pode chamar worktree.remove, que se recusa quando o worktree tem alterações não commitadas e deixa o branch no lugar.

A aba Git do painel direito mostra as mudanças da pasta ou do worktree como um diff. Você pode deixar uma nota em uma linha dele e entregar o conjunto ao agente que fez as mudanças.

1. Passe o mouse sobre uma linha do diff e clique no ícone de nota: Adicionar uma nota nesta linha, ou Editar nota em uma linha que já tem uma.
2. Digite a nota. Você salva com mod+Enter e cancela com Esc.
3. Quando você terminar de escrever, clique em Enviar N notas no fim do diff. Limpar todas as notas descarta tudo.

Cada nota chega ao agente com o arquivo, a linha, o código dessa linha e o seu comentário. O bloco é colado no painel do agente, mas não é enviado: o app avisa que você mesmo deve apertar Enter no painel, para poder acrescentar algo antes.

O envio é recusado, com o motivo exibido no botão, quando o app não sabe para qual painel enviar ou o painel não está pronto: nenhum painel de agente está trabalhando nesse worktree, vários estão, o painel não está em execução, tem texto digitado que você ainda não enviou ou não aceita blocos colados. A regra de digitação é a mesma que a Control Room usa.

A visão de chat mostra um painel de agente como um chat legível da conversa do próprio agente, desenhado sobre o terminal. Ela vem desativada por padrão. Ative com Visão de chat (experimental) em Configurações → Terminal.

• Funciona com Claude Code, Codex, OMP e Grok. Para outro agente, ou um shell comum, o painel avisa que o chat não está disponível. Ela não é oferecida em painéis SSH.
• Com a opção ativada, os painéis de agente abrem no chat. Cada painel guarda a própria escolha, que é lembrada entre reinicializações. O botão no cabeçalho do painel ou mod+Shift+J alterna o painel em foco entre Chat e Terminal. Desativar a opção devolve todos os painéis ao terminal.
• O chat é uma camada por cima. O processo do terminal por baixo não é afetado em nenhum dos casos.
• No Composer, Enter envia e Shift+Enter adiciona uma linha. Você pode anexar arquivos, colar imagens e escolher o modelo em um menu.
• No Claude Code e no Codex, um pedido de permissão que o MXterm Pro reconhece mostra Aprovar uma vez e Rejeitar e parar o agente. Para outros pedidos, o chat avisa que o agente está esperando no terminal.
• O botão de microfone no Composer é uma maquete. Ele não grava nada, não pede permissão de microfone e não insere texto.

A Control Room permite que agentes em painéis diferentes troquem mensagens, com você como Moderator. Aperte ⌘⌥B no macOS ou Ctrl+Alt+B no Windows e no Linux para abrir o painel direito e escolha a aba Control Room. O painel tem cinco abas: Control Room primeiro, depois Explorador, Histórico, Git e Visualização. A Control Room é a única com o nome escrito ao lado do ícone, as espadas cruzadas; as outras quatro mostram só o ícone, com o nome em um tooltip. O painel abre mais largo na aba Control Room. Cada aba de espaço de trabalho tem a sua própria sala, e o painel mostra só as salas da aba que você está vendo, com a sala principal primeiro. As salas de outras abas ficam em um menu Outras salas.

Adicione um painel com o botão Control Room (nós conectados) no cabeçalho dele. Ao adicionar, o painel direito abre na aba Control Room por conta própria, então você não precisa abri-lo antes. O botão mostra um pequeno + enquanto o painel não está em nenhuma sala e, quando está, ganha a cor do próprio painel. Uma pequena marca ao lado do ícone mostra o estado das mensagens do painel: um ponto cheio para mensagens novas, um anel vazio enquanto as mensagens esperam o painel ficar livre, um losango quando uma tarefa foi entregue a ele e um ponto dentro de um anel quando mensagens mais antigas foram puladas porque a fila estava cheia. Passe o mouse sobre a marca para ver o texto. O botão não aparece em painéis SSH, em um painel anexado de Máquinas (ele não executa nenhum terminal neste computador, então não pode entrar em uma sala) nem em painéis muito estreitos. Arrastar um painel para o painel direito não o adiciona.

• Adicionar à Control Room, ou Adicionar a "nome da sala" para uma sala existente, adiciona o painel e abre o painel direito.
• Nova sala cria uma sala e adiciona o painel à sala.
• Para um painel que já está em uma sala, o menu lista as outras salas em Trocar de Control Room (escolha uma para mover o painel) e oferece Sair da Control Room, que pergunta mais uma vez antes de remover o painel (a sessão continua em execução). Um painel pertence a uma sala por vez.

O menu de clique com o botão direito de um painel tem Copiar ID do painel. Para um painel que está em uma sala e já tem handle, ele também tem Copiar handle da sala, que copia o handle com o @, como @claude-2, e Mencionar na sala, que adiciona esse handle ao Composer da sala.

No painel direito, a aba da sala selecionada e a aba Members ou Discussion selecionada ficam preenchidas, para você ver com facilidade em qual está. A faixa de salas adiciona uma sala com +, renomeia uma com duplo clique ou com o ícone de lápis que aparece quando você aponta para ela, e exclui uma com o ✕ dela (a sala principal de uma aba não tem ✕ e não pode ser excluída). Members lista os painéis da sala. Clique em uma linha para ir até aquele painel; selecionar o nome ou a pasta para copiar não leva até ele. Clique com o botão direito em uma linha para renomear o painel. Cada linha tem um botão de copiar, que copia o handle do membro, como claude-2 (o valor que um agente coloca em to), um botão de coroa que define ou remove o coordenador (veja Control Room: o coordenador) e um ✕, sempre visível, que remove o painel da sala depois de perguntar mais uma vez. Um celular, ou outro computador pelo painel Máquinas dele (veja Painéis e divisões), cuja chave Pode gerenciar Control Rooms está ativada aqui (veja Acesso remoto e dispositivos) também pode criar uma sala, adicionar membros, remover um membro e excluir uma sala a partir da própria tela, sob os mesmos limites do plano Free; a sala principal de uma aba não pode ser excluída.

O botão Adicionar no topo de Members lista primeiro os painéis da aba da própria sala e depois os painéis das outras abas, sob o nome de cada aba, para que agentes de outras abas ainda possam entrar. Painéis SSH comuns, que não podem executar um agente, e painéis anexados de Máquinas não aparecem. Um painel que já está em outra sala fica esmaecido com Já está em "nome da sala". Clique em uma linha para marcá-la e depois em Adicionar N; Selecionar tudo e Limpar mudam todas as marcas de uma vez, e o + no fim de uma linha adiciona só aquele painel na hora. Adicionar três ou mais painéis de uma vez pede confirmação antes (Adicionar N painéis a "nome da sala"?). Se alguns painéis não puderem entrar, por exemplo porque a sala atingiu o limite do plano Free, uma nota sob o botão diz quantos e por quê, por cerca de 12 segundos.

Um membro sai de uma sala pelo ✕ dele, por Sair da Control Room no menu do painel, quando você move o painel com Trocar de Control Room, quando a sala é excluída ou quando o terminal dele termina. Arrastar uma linha não a remove. A Discussion registra cada saída e, quando sabe o motivo, termina a linha com ele: (its pane left this window), (removed from the Members list), (left from the pane menu), (its terminal ended) ou (its pane was not reopened).

As salas e os membros delas são salvos. Depois que você fecha e reabre o app, cada membro cujo painel foi restaurado volta para a sua sala, mostrado como sem handshake até o agente dele chamar mxt_room de novo. Um membro fica na lista como Aguardando reconexão por até 5 minutos, esperando o painel dele voltar; se o painel não voltar, o membro sai da sala. Quando um agente sai de volta para o prompt do shell, o MXterm Pro percebe em poucos segundos (ele verifica a cada 3 segundos, só no macOS e no Linux) e marca o membro como desconectado, e a Discussion diz <name> disconnected (its agent exited). O membro continua na sala e os claims dele são liberados. As mensagens deixam de ser digitadas no shell dele, e um broadcast o ignora. Ele se conecta de novo quando o agente é iniciado e chama mxt_room de novo.

Quando você adiciona um painel de agente, o MXterm Pro digita uma breve apresentação no prompt do agente, dizendo para ele chamar mxt_room.list_peers. Um painel não consegue se passar por você: um painel cujo nome contém "Moderator", em qualquer combinação de maiúsculas e minúsculas, entra como (pane, not the real Moderator) seguido do próprio nome, e um nome que reivindica o papel de coordenador recebe o prefixo (pane, not the coordinator) do mesmo jeito. Quando um agente que já viu as regras entra de novo em uma sala, ele recebe uma única linha com o nome da sala e do coordenador, em vez da apresentação completa. Até o agente fazer a primeira chamada mxt_room, o membro aparece como sem handshake e não pode receber mensagens. Um shell comum nunca faz essa chamada, e agentes sem configuração automática de MCP precisam da configuração manual descrita acima. O servidor MCP diz aos agentes para não chamar ferramentas mxt_room a menos que você tenha adicionado o painel deles a uma sala, e uma chamada de um painel que não está em nenhuma sala falha com um erro pedindo que o agente peça a você para adicioná-lo. Um membro conectado aparece como inativo quando o MXterm Pro não consegue ler o estado do agente dele (o estado é desconhecido ou o painel não tem detector de estado) e ele não faz nenhuma chamada mxt_room há mais de cinco minutos.

Um painel sem nome próprio recebe um nome e um handle formados pelo agente dele e por um número, por exemplo Claude 2 e claude-2. O agente é aquele com que o painel foi aberto ou, em um terminal comum, aquele que o MXterm Pro encontrou em execução nele. O número cresce por agente nessa sala e nunca é entregue a outro painel dela, então um handle antigo não chega a um recém-chegado. Os agentes endereçam o painel pelo handle; o id peer-, mais longo, ainda é aceito em to. Na Discussion, o handle de um membro atual aparece como esse nome. Um painel que você nomeou (veja Dar nome a um painel) usa esse nome. Um painel que você não nomeou recebe da sala um nome tirado do título do terminal, depois que esse título ficou igual por 2,5 segundos, sem o símbolo de estado. Um título que é só o nome de um shell, o nome do próprio agente, um caminho ou user@host não é usado. O nome na sala não muda o nome do próprio painel. Aponte para o botão Control Room de um painel para ver a sala e o handle dele.

A aba Discussion mostra as mensagens da sala como cartões: remetente e hora, depois para quem foi, com uma etiqueta Execute em um prompt. Escreva no Composer, na parte de baixo, como Moderator, escolha um destinatário e um modo, e aperte Enter para enviar (Shift+Enter adiciona uma linha). O Composer diz Para a sala: <nome> e fica desativado até pelo menos um membro estar conectado. Seu rascunho é guardado por sala, ao trocar de aba, de sala ou de espaço de trabalho, até você enviá-lo. Digitar @ lista os membros conectados; Enter ou Tab insere o handle deles, como @claude-2, no texto. A lista começa com uma linha Owner, que insere @owner para você, e uma coroa marca o coordenador. Uma mensagem que menciona @owner recebe um pequeno ponto. Uma menção só nomeia alguém na mensagem. Ela não muda o destinatário, que você escolhe no menu de destinatário. Você pode anexar até 5 imagens de até 10 MB cada a uma mensagem de Moderator. O MXterm Pro também foi feito para permitir que um celular pareado leia a sala e envie mensagens depois que você ativar Permitir que celulares vejam a Control Room, que vem desativado por padrão. Quando você rola para cima a partir da mensagem mais recente, um botão redondo com uma seta (Jump to latest) aparece no canto inferior direito com o número de mensagens que chegaram desde então; ele leva você de volta ao fim. Relatório (.md) no topo exporta a discussão.

Os agentes enviam com mxt_room.send nos mesmos dois modos e podem mandar mensagem para você como Moderator, colocando owner ou @owner em to; uma mensagem para você só pode ser um probe, já que você não tem terminal na sala. As mensagens deles aparecem na Discussion. O ícone de lixeira limpa a discussão e mantém os membros.

O MXterm Pro só digita em um painel depois que a saída dele ficou quieta por 3 segundos. Um agente que o MXterm Pro lê como inativo no prompt conta como quieto mesmo que o terminal dele continue imprimindo redesenhos. Ele também retém as entregas enquanto:

• o agente desse painel não estiver inativo (um agente esperando em uma caixa de permissão conta, e o MXterm Pro consegue ver isso nos agentes cujo estado ele lê), ou
• o painel for um terminal comum em que o MXterm Pro encontrou um agente em execução (ele lê o programa em primeiro plano do painel, e só para agentes conhecidos como claude, codex, gemini, omp e grok) e não conseguir ler o estado desse agente, como no GitHub Copilot e no Amp: uma caixa de permissão pode estar aberta, ou
• você tiver uma linha não enviada nesse painel (um rascunho não enviado no Composer do chat do painel conta), ou tiver apertado uma tecla nele nos últimos 6 segundos enquanto ele está em foco, ou
• o painel não aceitar blocos colados (o bracketed paste está desligado, como em um shell comum) e uma mensagem tiver mais de uma linha: ela seria executada linha por linha, então não é digitada. O painel avisa isso e oferece Dispensar, mas não Entregar agora.

Um painel aberto como terminal comum também conta como agente quando o MXterm Pro vê rodando nele um dos agentes cuja tela ele lê, por exemplo claude digitado em um prompt de shell. Ele passa a ter um estado, e as mensagens dele são entregues pelas mesmas regras de um painel aberto a partir de um modelo de agente. O MXterm Pro lê o programa em primeiro plano de um painel no macOS e no Linux. No Windows ele não lê, então lá um painel comum continua comum, não importa como você inicie um agente nele.

Enquanto há mensagens na fila, o cabeçalho do painel fica âmbar. Quando elas estão retidas, o painel mostra quantas mensagens estão esperando, com um botão Entregar agora, e a aba da sala mostra ⏸ com a contagem. A linha do membro em Members também mostra ⏸ e a contagem. Entregar agora envia as mensagens mesmo que o agente esteja ocupado ou você esteja digitando, mas ainda espera a saída do painel ficar quieta. Enquanto o agente trabalha e o painel ainda está imprimindo, a pílula não tem botão e mostra Aguardando o agente ficar livre; depois que você pressiona Entregar agora, ela mostra Envia quando o agente ficar livre. Uma retenção que dura 10 segundos gera um banner Mensagens aguardando envio, depois no máximo dois lembretes com 2 minutos de intervalo, até a fila esvaziar.

Ao lado, Dispensar (✕) descarta a fila sem digitar nada. Uma fila de avisos some com um clique, e as mensagens continuam na caixa de entrada do agente. Uma fila que contém um Execute pede um segundo clique (Descartar?), porque esse texto é colado e não fica guardado em nenhum outro lugar; o remetente é avisado de que ele foi dispensado. Um aviso que ficou obsoleto, porque o agente já leu todas as mensagens que ele anuncia, é descartado em vez de digitado.

mxt_room.list_peers diz a cada agente quem está na sala. Cada peer tem um state (working, blocked quando espera em uma caixa de permissão ou em uma pergunta, done, idle, ou none quando o MXterm Pro não consegue ler aquele painel) e agentSource, que diz se o painel foi aberto como aquele agente (template) ou se o MXterm Pro viu o agente em execução (process). O lugar do Moderator traz isModerator: true; esse é o único campo que identifica a pessoa que está conduzindo o app, já que o nome de um painel pode dizer qualquer coisa. O coordenador da sala, se você definiu um, traz isCoordinator: true.

Chamado com changesOnly: true, mxt_room.list_peers retorna só os peers cuja entrada mudou desde a última chamada daquele agente. A nota explicativa longa vem apenas na primeira chamada de um agente. O unreadFromYou de um peer diz quantas das suas mensagens ele ainda não viu, e está ausente quando não há nenhuma. Uma mensagem conta como vista quando o peer a leu com mxt_room.read_inbox, quando um aviso que a citava por inteiro foi digitado no painel e enviado, ou quando o peer respondeu a você. Uma mensagem vista da segunda ou da terceira forma continua na caixa de entrada até que o peer a leia. As descrições das ferramentas da Control Room que os agentes recebem são mais curtas, então os agentes gastam menos tokens com elas.

Um agente que ficou ausente pode chamar mxt_room.digest para um resumo curto da própria sala: as mensagens dirigidas a ele que ainda não respondeu, as mensagens mais recentes, quem tem quais arquivos e quem está bloqueado. Ele só lê: não limpa a caixa de entrada do agente e nunca mostra outra sala.

Você, como Moderator, pode transformar um membro em coordenador da sala. Aponte para a linha do membro em Members e clique no botão de coroa (Definir como coordenador). Clique de novo (Remover coordenador) para limpar o papel. Só você pode defini-lo, a partir do app. Um agente não pode, e o nome de um painel não consegue reivindicá-lo.

• Uma sala tem no máximo um coordenador. Tornar outro membro coordenador substitui o primeiro, e o papel termina quando esse membro sai da sala.
• Em uma sala com coordenador, só o coordenador e você podem fazer broadcast, isto é, enviar uma mensagem sem destinatário. Todos os outros membros precisam enviar a um peer, em geral o coordenador. O app recusa qualquer outro broadcast com um erro que cita o coordenador. Passar uma tarefa com execute tem o mesmo limite, enquanto qualquer membro ainda pode enviar um probe a um peer. Em uma sala sem coordenador, cada agente pode fazer broadcast no máximo 3 vezes a cada 60 segundos, e um broadcast é recusado quando há mais de 12 peers conectados; as mensagens um a um não são afetadas.
• Definir ou limpar o papel envia a cada membro uma mensagem automática e adiciona uma linha à Discussion, como <name> is now the coordinator. A mensagem também diz que push, deploy, release e delete ainda exigem uma mensagem sua (fromModerator: true): o coordenador só propõe. Um agente que entra depois é informado de quem é o coordenador na apresentação dele.
• mxt_room.list_peers marca o coordenador com isCoordinator: true. Como isModerator, isso vem do papel, não de um nome.

Dois agentes podem acabar alterando o mesmo arquivo. Para evitar isso, um agente reserva arquivos ou pastas com mxt_room.claim antes de editá-los, até 10 em um claim. Se algum deles estiver dentro de um claim que outro peer ainda mantém, o claim é recusado e a resposta diz quem o mantém. Um claim é apenas um aviso: ele não impede ninguém de gravar em um arquivo.

Um claim dura 15 minutos depois da última chamada mxt_room do dono. Ele também termina quando o dono sai da sala, quando o agente dele volta para o prompt do shell ou quando você clica no ✕ que aparece na linha de cadeado dele na aba Members ao apontar para a linha. Esse clique libera todos os claims daquele membro e é a saída para um agente travado que segura arquivos de que outro precisa. Um membro pode ter no máximo 5 claims.

Na aba Members, o membro que tem um claim mostra, sob o nome, uma linha com um cadeado.

• Por padrão, o plano Free permite 2 painéis em uma sala; adicionar um terceiro abre o aviso de upgrade. O Free também permite uma Control Room com membros por vez: uma sala sem membros não conta, então você ainda pode criar quantas salas quiser, mas colocar um painel em uma segunda sala enquanto outra tem membros abre o aviso de upgrade. Mover o único membro de uma sala para outra é permitido. O próprio app aplica os dois limites. O mxterm.net pode definir outros números. Uma mudança vale para os painéis adicionados depois e não remove membros nem salas que você já tem. O plano Pro não tem limite em nenhum dos dois. Veja os preços.
• Cada agente pode enviar no máximo 20 mensagens e claims a cada 60 segundos; o Moderator não tem limite.
• Uma mensagem pode ter no máximo 8.192 bytes.
• Uma caixa de entrada guarda as 50 mensagens mais recentes na memória e descarta as mais antigas. Depois de uma reinicialização, o MXterm Pro mantém no máximo as 20 mensagens não lidas mais recentes por membro, 256 KiB no total, e nada com mais de 24 horas.
• Se o servidor MCP falhar ao iniciar, a Control Room fica indisponível nessa execução e adicionar um painel falha.