← graph

research-document-the

Research: document the EXACT spawn semantics for each handler (claude, codex, nex)

Metadata

Statusdone
Assignedagent-1087
Agent identityf51439356729d112a6c404803d88015d5b44832c6c584c62b96732b63c2b0c7e
Created2026-04-29T12:21:14.082721372+00:00
Started2026-04-29T12:21:36.180083188+00:00
Completed2026-04-29T12:25:55.902732281+00:00
Tagspriority-high,research,docs,architecture, eval-scheduled
Eval score0.93
└ blocking impact0.90
└ completeness0.98
└ coordination overhead0.95
└ correctness0.95
└ downstream usability0.90
└ efficiency0.85
└ intent fidelity0.88
└ style adherence0.92

Description

Description

The chat agent has been hand-waving about 'in-process nex' vs CLI handlers without an authoritative answer. The author is asking for ground truth, not speculation. This task produces a doc paragraph + file:line citations that the chat agent (and any future agent) can quote.

Specific questions to answer (with file:line citations)

  1. Per-handler spawn mechanism. For each of: claude-cli, codex-cli, nex (local/openrouter/oai-compat) — what exact syscall / process tree happens when the dispatcher spawns a worker for a task? Is it:

    • exec() of an external binary (claude / codex)
    • exec() of wg itself with a subcommand (e.g. wg spawn-task, wg nex)
    • fork() without exec
    • tokio task / thread within the dispatcher process
    • PTY-wrapped child of any of the above

  2. Where is the LLM HTTP client? For each handler:

    • Does the wg binary's compiled code make the API call directly (reqwest / hyper / etc.)?
    • Does an external CLI (claude / codex) make the call?
    • Or both, depending on context?

  3. Is the term 'in-process' accurate? When CLAUDE.md says 'in-process nex handler', does that mean:

    • The HTTP client lives in wg's compiled code (true regardless of whether the worker is a subprocess), OR
    • The worker actually runs in-process (same PID as dispatcher), OR
    • Something else? Settle this so we stop saying it ambiguously.

  4. What runs in each worker process? When wg agents shows agent-2 task-id codex 1736117 25s working:

    • PID 1736117 is what binary? (claude / codex / wg / something else)
    • What command line did it get exec'd with?
    • How does it receive the task spec (env vars, stdin, IPC socket, file)?
    • How does it report status back (exit code, file write, IPC)?

  5. Where in the source does this live? Cite the canonical files. Likely:

    • src/dispatch/handler_for_model.rs
    • src/dispatch/spawn.rs (or wherever exec happens)
    • src/commands/spawn_task.rs (if that's the worker entrypoint)
    • src/handlers/{claude,codex,nex}.rs (or whatever the file structure is)

Deliverable

A single wg log research-spawn-semantics entry with:

  • A clean prose paragraph (3–5 sentences) explaining the architecture, suitable for pasting into CLAUDE.md or docs/
  • A table: handler → worker PID identity → HTTP client location
  • File:line citations for the 3-5 most authoritative source locations (where the exec() actually happens, where the model spec gets parsed into a handler choice, where the LLM call is made)
  • Direct quotes (1-2 lines) from those source locations so the answer is verifiable without re-grepping

The deliverable is the LOG ENTRY, not a code change. No source modifications.

Validation

  • Log entry posted via wg log research-spawn-semantics
  • Each of the 5 questions above has a direct, citation-backed answer (not hand-waving)
  • File:line citations present and accurate (re-grep should find the cited content)
  • No 'probably' / 'likely' / 'I believe' qualifiers in the deliverable — this is supposed to be ground truth

Depends on

Required by

Log