[Bug] Codex session resume rejects subagent_spawned and subagent_state_update with Invalid params

[HalfSweet]

Affected area

Agent runtime / ACP

Installation method

Desktop release

Lody version or commit

0.101.0

Operating system

macOS 27.0 arm64

Agent or runtime

Built-in Codex through Lody's bundled codex-acp.js. The Codex rollout records originator: acp-extension-codex and cli_version: 0.156.0.

The affected conversation used gpt-6-astra with reasoning effort ultra.

What happened?

When Lody restored an existing Codex conversation containing three native subagents, the ACP client logged six Error handling notification failures with JSON-RPC error -32602 / Invalid params:

• Three session/update notifications with sessionUpdate: 'subagent_spawned'.
• Three session/update notifications with sessionUpdate: 'subagent_state_update'.
• Each of the three existing subagents appeared once in each group.

These errors occurred during restoration on 2026-09-29 at approximately 05:17:24 UTC, immediately before Lody confirmed that the original ACP session had been resumed.

I investigated because later conversation turns appeared to use subagents less visibly. The underlying Codex rollouts show that the subagents continued executing: a subsequent implementation turn made seven followup_task calls and thirteen send_message calls; a later repair turn made two and three respectively. These calls reused the existing subagents rather than creating new ones.

Confirmed impact: the ACP notification handling path rejects the restored subagent notifications. Incomplete subagent visibility/state in Lody is a possible user-facing consequence, but I have not independently verified the exact UI effect or whether another event path compensates for the rejected notifications. This report does not claim that Codex stopped delegating or that inference settings were downgraded.

What did you expect?

The bundled Codex adapter and Lody's ACP receiver should agree on the supported subagent notification protocol when restoring a conversation. Existing subagents and their restored states should be handled without Invalid params errors, and subsequent activity should remain observable.

If these notification variants are legacy or require capability negotiation, the adapter should translate/gate them appropriately instead of sending variants the receiver rejects.

How can we reproduce it?

Observed sequence; this has not yet been reduced to a standalone reproduction:

1. Use the desktop release with the built-in Codex provider, gpt-6-astra, and reasoning effort ultra.
2. Run work that creates native subagents, then continue the same conversation over multiple turns.
3. Resume that conversation after it is no longer resident in Lody's process memory. In the observed case, the log explicitly reported Session not found in memory; restoring, followed by resuming the original ACP session ID. The cause of the earlier unloading is not established.
4. Inspect the local daemon/desktop logs during restoration for Error handling notification, subagent_spawned, and subagent_state_update.
5. Continue work and compare the native Codex subagent activity with Lody's displayed/persisted subagent state.

How often does it happen?

Only once

One restored conversation inspected; six notification failures in that restoration. Reproducibility across other sessions, fresh sessions, and current development builds has not been established.

Relevant log output

Abbreviated excerpts with session IDs replaced by placeholders and process prefixes omitted. No conversation contents or project paths are included.

2026-09-29T05:17:24.387Z Error handling notification {
  jsonrpc: '2.0',
  method: 'session/update',
  params: {
    sessionId: '<parent-session>',
    update: {
      sessionUpdate: 'subagent_spawned',
      subagentSessionId: '<child-session>',
      name: '<redacted>',
      task: '<redacted>',
      capabilities: {}
    }
  }
} {
  code: -32602,
  message: 'Invalid params',
  data: {
    _errors: [ 'Invalid input', ... ],
    sessionUpdate: { _errors: [Array] },
    ...
  }
}

2026-09-29T05:17:24.514Z Error handling notification {
  jsonrpc: '2.0',
  method: 'session/update',
  params: {
    sessionId: '<parent-session>',
    update: {
      sessionUpdate: 'subagent_state_update',
      subagentSessionId: '<child-session>',
      state: 'completed'
    }
  }
} {
  code: -32602,
  message: 'Invalid params',
  data: {
    _errors: [ 'Invalid input', ... ],
    sessionUpdate: { _errors: [Array] },
    ...
  }
}

The run configuration was applied successfully before the next user turn:

2026-09-29T05:17:24.637Z ACP session config option set: reasoning_effort=ultra

Additional context

• All fourteen distinct parent turns inspected (eighteen turn_context records) retained gpt-6-astra / ultra. The three child rollouts also recorded that combination. The initial resume handshake reported gpt-6-astra[xhigh], but Lody explicitly reapplied ultra before submitting the next turn; the handshake value alone is not evidence of a downgrade.
• The initial conversation configuration enabled proactive delegation; no later disabling instruction was found in the inspected rollout.
• Potential investigation area: compatibility/capability negotiation between the bundled Codex adapter's resume notifications and the ACP receiver's accepted session/update variants. This is a hypothesis from the rejected payloads, not a confirmed source-level root cause.
• Related integration: feat: integrate builtin subagent events and activity history UI #996. That PR describes the Core subagent-events integration; please check whether the packaged resume path still emits the variants shown above.
• Related visibility report: [Bug] Task lifecycle progress never reaches history, so the panel cannot show the running tool #445 concerns filtering task progress from persisted history. This report concerns explicit Invalid params errors for Codex subagent notifications during restoration, and does not assume the same root cause.

Before submitting

• I searched the existing issues and did not find a duplicate.
• This report concerns an open-source component in this repository, not a hosted service, Web or mobile app, account, or billing issue.
• This is not a security vulnerability; security reports follow the repository's security policy.
• I removed credentials, private source, conversations, prompts, personal data, and other sensitive information.