Handoff: Hermes weekly Codex multi-agent watch

2026-07-29 20:52 JST · Hermes agent on XPS13 · generated by Codex

Continuation target

On the Hermes machine (ssh xps13 from Miro's main machine), create a native weekly Hermes run that monitors official Codex multi-agent changes. Run it once immediately to establish a baseline, then schedule it weekly. It must be read-only and report meaningful deltas; it must not update Codex, rewrite configuration, or change agent policy automatically.

Current state

[agents]
enabled = true
max_concurrent_threads_per_session = 4
default_subagent_model = "gpt-5.6-terra"
default_subagent_reasoning_effort = "medium"

The global policy says to use fork_turns="none" by default, a small recent-turn window such as "3" when necessary, and "all" only exceptionally.

Ordered implementation

  1. Inspect the existing Hermes installation, scheduler, notification route, and conventions. Prefer Hermes's native scheduled-run mechanism; use a user-level systemd timer only if Hermes has no scheduler. Do not invent a second orchestration stack.
  2. Create a durable state file in the existing Hermes state/config hierarchy. Store the last checked timestamp, installed and latest Codex versions, source fingerprints or relevant release identifiers, and the last known answers to the watch questions below.
  3. Run the monitor once immediately, persist the baseline, and deliver its first report through Hermes's normal user-facing channel.
  4. Schedule it weekly at a low-noise local time. Record the exact schedule, command/prompt, state path, log path, and how to run or disable it manually.
  5. Verify the scheduled unit/job is active and execute one manual dry run through the same entrypoint used by the scheduler.

Sources to check

Questions the weekly run must answer

  1. Did the stable Codex version change, and do its release notes mention agents, subagents, multi-agent V2, delegation, forks, inherited history, context, thread lineage, or concurrency?
  2. Did the default or allowed values of fork_turns change?
  3. Is there now a documented global config setting for child-context inheritance?
  4. Is selective context packing, summarization, continuous parent-child synchronization, or another context-sharing mechanism now documented?
  5. Did proactive delegation behavior, built-in roles, model selection, reasoning effort, concurrency, sandbox inheritance, or permission inheritance change?
  6. Do any changes justify reconsidering the current fork_turns="none" operational policy?

Reporting contract

Produce a compact report with: Verdict, Material changes, What remains unchanged, Recommended action, and direct official-source URLs. Distinguish product changes from model-quality impressions. If nothing material changed, send only a one-line heartbeat with the checked version and date. Never claim a schema/default changed based only on release-note wording.

Verification and acceptance

Risks and open questions

Suggested skills