A Control UI do OpenClaw

Você instalou o OpenClaw, iniciou o Gateway e leu em algum lugar que existe um painel no navegador. Abri-lo é questão de uma URL, mas a página que carrega pede um Gateway secret que ninguém passou para você, e o endereço de LAN impresso no terminal pode nem responder a partir do seu notebook. Veja o que a Control UI realmente é, o que esse campo único aceita e o que faz a lista de agentes por trás dela.

O que o Gateway serve na porta 18789

• A Control UI é um pequeno app de página única feito com Vite e Lit e servido pelo próprio Gateway, em http://your-host:18789/ por padrão, com um prefixo opcional quando você define gateway.controlUi.basePath, por exemplo /openclaw. Ela fala diretamente com o WebSocket do Gateway na mesma porta, então não há um segundo serviço para iniciar nem um host de API separado para onde apontá-la.
• No host do Gateway, abra http://127.0.0.1:18789/ ou http://localhost:18789/. Se a página não carregar de jeito nenhum, inicie primeiro o Gateway com openclaw gateway.
• gateway.controlUi.enabled é aplicado a quente. Desative-o e o Gateway para de servir as páginas e os recursos do painel, enquanto os bots e as conexões existentes com o Gateway continuam funcionando; reative-o e o serviço é retomado, com os recursos que faltarem preparados em segundo plano. Alterar o caminho base de onde o painel é servido ou a raiz dos recursos ainda exige reiniciar o Gateway.
• Se a URL da LAN funciona no host, mas não a partir de outra máquina, suspeite do host antes da rede. Quando o Gateway escuta na LAN no Windows nativo, o Firewall do Windows ou uma Group Policy gerenciada pela organização pode bloquear a URL de LAN anunciada mesmo quando 127.0.0.1 funciona no host do Gateway, e openclaw gateway status --deep, executado nesse host Windows, aponta portas provavelmente bloqueadas, perfis incompatíveis e regras de firewall locais que a política pode ignorar.

Uma conexão direta por loopback não dispensa a autenticação por token ou por senha.

Por que a página na sua própria máquina ainda pede um segredo

A autenticação acontece durante o handshake do WebSocket, não em um formulário de login que o app poderia pular discretamente para visitantes locais. O Gateway aceita o segredo compartilhado configurado em connect.params.auth.token ou em connect.params.auth.password, e gateway.auth.mode seleciona qual valor configurado se aplica; ele também aceita cabeçalhos de identidade do Tailscale Serve quando gateway.auth.allowTailscale é true, e cabeçalhos de identidade de proxy confiável quando gateway.auth.mode é trusted-proxy. A autenticação do Gateway acontece antes do pareamento de dispositivos, então um navegador se identifica com o segredo compartilhado antes mesmo de poder registrar uma solicitação de pareamento. Um navegador em loopback direto só dispensa o segredo compartilhado quando gateway.auth.mode está explicitamente definido como none, o que desativa por completo a autenticação do gateway e não é a configuração recomendada para a Control UI.

Um campo, dois tipos de valor

• A tela de login e Settings, depois Gateway, usam o mesmo campo único Gateway secret: cole o token ou digite a senha. O navegador não escolhe o modo; gateway.auth.mode já o escolheu no host.
• Depois de uma conexão bem-sucedida, a UI guarda o segredo no armazenamento de sessão, restrito à aba atual do navegador e à origem do Gateway, e somente quando o Gateway informa autenticação por token. Senhas ficam na memória e nunca são persistidas, e, depois que o dispositivo é pareado, o navegador pode usar o token por dispositivo que armazenou nas conexões seguintes.
• Um código de configuração copiado em Devices, Pair device, Copy setup code é uma credencial diferente. Cole um em Gateway secret e a UI mostra uma dica logo no formulário antes de você se conectar: esse código vai em Settings, depois Gateway, no app móvel do OpenClaw, enquanto a Control UI quer o token compartilhado de openclaw gateway auth-token --show, executado em um terminal interativo no host do Gateway.

Um estado parece bug e não é. O onboarding local gera por padrão um Gateway secret em modo token, sem seletor entre token e senha, e preserva um modo senha já existente; para configurar explicitamente uma senha, use --gateway-auth password ou --gateway-password com o valor que você escolher, e o Tailscale Funnel exige o modo senha. Mas, se o Gateway inicia em modo token sem token configurado, ele gera em vez disso um token de execução efêmero para aquele processo. Esse token não é gravado na configuração, então não pode ser recuperado, e um navegador em loopback sem ele é rejeitado: o campo à sua frente pede um valor que não existe em nenhum lugar onde você possa lê-lo. A saída é executar openclaw doctor --generate-gateway-token, reiniciar o Gateway, depois executar openclaw gateway auth-token --show em um terminal interativo e colar o resultado em Gateway secret; o artigo sobre o doctor do OpenClaw detalha o que mais essa ferramenta de reparo pode alterar, e o artigo que explica o Gateway descreve o próprio processo que ocupa a porta.

A lista de agentes e o modo equipe

Abra Agents na barra lateral, escolha All agents no seletor de agentes ou acesse /agents, e você recebe uma lista em vez de um chat: um cartão por agente configurado, com sua identidade, seu modelo, o status de trabalho atual, a última atividade e uma prévia do chat principal, com os agentes em atividade primeiro e os mais recentemente ativos logo atrás. Open chat leva à sessão principal desse agente, Manage agents abre /settings/agents e New agent abre o chat do custodian, que recomenda um chefe de gabinete, um pesquisador, um redator, um revisor ou uma pequena equipe com os quatro, usando os mesmos templates de função da CLI e aguardando a aprovação do operador antes de criar qualquer coisa. Escolher Show all agents ativa o modo equipe: as sessões se reagrupam sob cabeçalhos de agente recolhíveis, na ordem configurada da lista, a linha superior vira um cabeçalho de espaço de trabalho com o nome de exibição configurado do Gateway, e o escopo de página compartilhado passa a ser All agents por padrão, de modo que Automations, Dashboards, Sessions, Tasks e Usage mostram linhas de vários agentes, com a identidade do agente anexada. O modo equipe é uma preferência do navegador, desativada por padrão e lembrada por gateway naquele navegador, então o mesmo Gateway acessado a partir de outro perfil ou por acesso remoto ao OpenClaw começa no modo de agente único até você ativá-lo ali também. Como vários agentes isolados acabam dentro de um único processo do Gateway é um assunto à parte, tratado em um artigo sobre vários agentes em um só Gateway.

Na Diali

A Diali hospeda o OpenClaw, então a porta, o token e o certificado deixam de ser problema seu: cada cliente roda o próprio assistente na própria instância, e servimos a Control UI por HTTPS em um endereço real, em vez de uma URL de LAN em texto puro. A configuração de execução é gerada a partir do seu painel da Diali e reescrita do zero a cada nova versão, então o que roda sempre corresponde ao que você selecionou, e o estado do agente fica em um volume persistente, com snapshots diários e restauração em um clique disponíveis pelo complemento Backups (incluído no Max). O OpenClaw hospedado na Diali descreve o que o assistente hospedado inclui, e a página de preços da Diali lista os planos.

• O painel é o próprio Gateway, em uma única porta.
• Um navegador em loopback ainda precisa do segredo configurado.
• Um token de execução efêmero nunca pode ser lido de volta.