Configuração do OpenClaw para automação de navegador com humano no circuito usando Docker, Chromium e noVNC

Um desenvolvedor no r/openclaw documentou sua configuração para permitir que o OpenClaw lide com tarefas que exigem intervenção humana, como resolução de CAPTCHAs e aprovações durante sessões automatizadas de navegador. A solução usa um contêiner Docker com Chromium, noVNC e ferramentas relacionadas para permitir intervenção remota quando necessário.

Como funciona

O agente controla um navegador headless através do Chrome DevTools Protocol (CDP). Quando encontra um CAPTCHA ou precisa de aprovação humana, ele envia uma notificação no Telegram. O usuário abre uma URL noVNC no celular ou laptop para visualizar e interagir com o navegador, então responde "pronto" para permitir que o agente continue. A configuração requer aproximadamente 300MB de RAM com um tempo de inicialização a frio de 3 segundos.

Aplicação prática

O desenvolvedor testou esta configuração fazendo o OpenClaw agendar uma coleta de encomendas. Após fornecer fotos de notas de remessa e e-mails, o agente preencheu o formulário online, selecionou datas e o enviou enquanto o desenvolvedor monitorava via noVNC. Eles observaram que o widget Chromium do Claude Opus 4.6 teve dificuldades com a mesma tarefa, ficando preso em loops de navegação enquanto o OpenClaw completava o agendamento.

Implementação técnica

O contêiner Docker executa:

• Xvfb para display virtual
• Chromium com Playwright
• x11vnc e noVNC para visualização remota
• supervisord para gerenciamento de processos

O bot controla o Chromium via CDP de dentro do contêiner, enquanto os usuários visualizam o navegador através do noVNC de qualquer dispositivo com uma URL simples (sem aplicativo necessário).

Medidas de segurança

• noVNC acessível apenas via Tailscale (dispositivo cliente deve fazer parte da tailnet)
• Porta CDP vinculada apenas ao localhost
• Contêiner não tem acesso ao sistema de arquivos do host
• Chromium executa sem privilégios
• Senhas/2FA tratadas via painel de área de transferência do noVNC diretamente

Fortalecimento adicional

• Verificação de saúde do Docker: consulta CDP a cada 30s, 3 tentativas antes de ficar não saudável
• Limites de recursos: 1GB RAM + 2 CPUs
• Poda de abas: mantém no máximo 5 abas, fecha abas em branco, executa a cada 5 minutos
• Contêiner permanece isolado sem montagens do host

Configuração do Docker

O Dockerfile usa Ubuntu 24.04 e instala:

FROM ubuntu:24.04
ENV DEBIAN_FRONTEND=noninteractive
ENV DISPLAY=:99
ENV RESOLUTION=1920x1080x24
RUN apt-get update && apt-get install -y --no-install-recommends \
    ca-certificates xvfb x11vnc fonts-liberation \
    dbus-x11 supervisor curl gnupg websockify novnc \
    && rm -rf /var/lib/apt/lists/*
RUN curl -fsSL https://deb.nodesource.com/setup_20.x | bash - \
    && apt-get install -y nodejs \
    && npx playwright install --with-deps chromium \
    && rm -rf /var/lib/apt/lists/*
RUN useradd -m -s /bin/bash browser \
    && mkdir -p /home/browser/.cache \
    && cp -r /root/.cache/ms-playwright /home/browser/.cache/ \
    && chown -R browser:browser /home/browser
COPY supervisord.conf /etc/supervisor/conf.d/supervisord.conf
COPY start-chromium.sh /usr/local/bin/start-chromium.sh
RUN chmod +x /usr/local/bin/start-chromium.sh
RUN ln -sf /usr/share/novnc/vnc.html /usr/share/novnc/index.html
EXPOSE 6080 9222
CMD ["/usr/bin/supervisord", "-c", "/etc/supervisor/conf.d/supervisord.conf"]

O supervisord.conf gerencia quatro processos: Xvfb, Chromium, x11vnc e noVNC/websockify.

O script start-chromium.sh inicia o Chrome com flags específicas incluindo --remote-debugging-port=9222 --remote-debugging-address=0.0.0.0 para acesso CDP.

Itens TODO

O desenvolvedor planeja adicionar autenticação por token no noVNC e implementar um recurso de parada automática após tempo de inatividade.