codex-a2a-setup

Set up Codex A2A Gateway

Complete the requested installation using the existing CLI; this skill is the setup workflow. Preserve the user's selected host, workspace, mode, and existing authentication. Ask only for required values that cannot be obtained from the request or current configuration.

Read runtime.json, generated by install-skills, for the absolute Python command array. Append CLI arguments to that array using a subprocess argument list; do not execute a JSON string as shell code. Run --version and --help before configuration. The reference contains no credentials and works outside the original checkout. If its Python was moved or removed, reinstall the package/skills using the selected replacement environment; do not silently select an unrelated PATH executable.

1. Determine outbound (Codex asks Hermes), inbound (A2A client asks Codex), or both. Reuse a settled choice; ask once if direction is materially unknown. Only inbound needs an explicit Codex workspace. Generic inbound A2A clients do not require Hermes.
2. Inspect existing registrations and selected host prerequisites. Outbound requires a configured Hermes default agent and active local Hermes A2A platform. Inbound requires a Codex CLI with existing sign-in and accessible workspace. Provider login belongs to Codex/Hermes: there is no universal gateway API key. Do not solicit or print tokens in chat.
3. Follow the relevant sections of workstation configuration. Preserve unrelated client entries and Hermes settings. Keep A2A on loopback. Use an absolute, persistent launcher when configuration must survive GUI launches; shell-only export is insufficient. Install startup services only when the user requests or opts into automatic startup.
4. Run doctor --mode for the selected direction through the same launcher/environment used at runtime. Outbound mode checks Hermes; inbound mode checks the local gateway, workspace and Codex executable without Hermes. Read-only checks do not prove sign-in or model execution. Confirm MCP registration and tool discovery from a fresh client session. Already installed skills can be checked with install-skills --check --dest <current-skills-root> (derive the root from this skill directory, retaining a custom install destination); differing managed files require review before --replace.
5. If the user has authorized a live model test, send one harmless uniquely identified task for each selected direction and retrieve its result. Otherwise report live execution unverified. Retain stable task handles; never resend after an ambiguous timeout.

If a gateway-created Codex worker needs RAG, verify local-rag-mcp registration in the actual execution host/Codex configuration and verify discovery or a harmless retrieval in that worker context. Same-host configuration may already provide it; Desktop-injected tools/plugins are not automatically inherited. Do not infer availability from the Desktop tool list or gateway health.

Finish with installed runtime, selected direction/workspace, readiness evidence, and any missing prerequisite. Distinguish configured transport from verified model execution. For normal work use the installed codex-a2a skill; do not rerun setup for every task.