Menu
Fix Docker containers unable to reach accounts.google.com for OAuth — caused by IPv6 preference
Installer avec Codex ou Claude Copiez ce prompt, collez-le dans Codex, Claude ou un autre assistant, puis laissez-le vérifier la page du skill et l'installer pour vous.
Basé sur la classification professionnelle SOC
Transforms the Hermes agent from a reactive question-answerer into a proactive autonomous executor. ARCHITECT takes any high-level goal, decomposes it into a dependency-aware task graph, executes each step with validation, self-corrects on failure, and delivers results — all without hand-holding. The missing execution layer for personal AI agents. Zero dependencies. Zero config. Works with any model. Pairs with apex-agent and agent-memoria for the complete autonomous agent stack.
Auto-reflective self-improvement skill — extracts learnings from corrections and success patterns, permanently encodes them into memory and skills. Philosophy: Correct once, never again.
Orchestrate multi-agent teams with defined roles, task lifecycles, handoff protocols, and review workflows. Use when: (1) Setting up a team of 2+ agents with different specializations, (2) Defining task routing and lifecycle (inbox → spec → build → review → done), (3) Creating handoff protocols between agents, (4) Establishing review and quality gates, (5) Managing async communication and artifact sharing between agents.
Integrate existing autonomous agents (like Hermes) into multi-agent orchestration platforms (AionUI, LangChain, etc.) via ACP over stdio.
MiniMax Agent Platform (agent.minimax.io) — MaxHermes, MaxClaw, Skills marketplace. Relacao com Hermes Agent (NousResearch) e OpenClaw.
Paperclip AI agent operations — creating agents with hierarchy, autonomous operation via hierarchical issues, and troubleshooting. Use when: creating agents, setting up org hierarchy, recovering from errors, or monitoring agent health.
| name | docker-ipv6-google-oauth-fix |
| description | Fix Docker containers unable to reach accounts.google.com for OAuth — caused by IPv6 preference |
| tags | ["docker","networking","ipv6","oauth","google"] |
Container Docker não consegue completar OAuth Google (login "Continue with Google") — timeout em accounts.google.com ou oauth2.googleapis.com/token, mas www.google.com funciona.
# Testar do container
docker exec <container> sh -c "curl -v https://accounts.google.com 2>&1 | head -20"
# Timeout = problema IPv6
# Testar no host
curl -v --connect-timeout 5 https://accounts.google.com 2>&1 | head -10
# Funciona = rede do host OK, problema é do container
# Temporário (até reiniciar)
sysctl -w net.ipv6.conf.all.disable_ipv6=1
sysctl -w net.ipv6.conf.default.disable_ipv6=1
# Permanente — adicionar a /etc/sysctl.conf:
net.ipv6.conf.all.disable_ipv6 = 1
net.ipv6.conf.default.disable_ipv6 = 1
O Google tem IPv6 para www.google.com mas bloqueia/sempre responde em IPv4 para accounts.google.com e oauth2.googleapis.com. O container prefere IPv6 (devido a rotas de host) e falha. O host funciona porque usa IPv4 por defeito.
accounts.google.com → timeout (DNS resolve para IPv6, conexão falha)oauth2.googleapis.com/token → POST funciona (GET falha)www.google.com → funcionawww.googleapis.com → funcionasysctl net.ipv6.conf.all.disable_ipv6 # deve mostrar 1
sysctl net.ipv6.conf.default.disable_ipv6 # deve mostrar 1
# Testar do container
docker exec <container> sh -c "curl -s -o /dev/null -w '%{http_code}' https://accounts.google.com"
# Deve retornar 301 ou 302, não timeout
cd /caminho/do/docker-compose
docker-compose down
docker-compose up -d