[shoedog]

Problem

After a new session's first turn, the codex-acp adapter starts an ephemeral title-generation thread and never unsubscribes it (upstream issue agentclientprotocol/codex-acp#628, fix PR agentclientprotocol/codex-acp#629, both open). The bridge has no id for that thread, so session/close (#131) cannot reach it. Its codex-config-level MCP servers (for example prism-mcp, node_repl) live until the adapter exits, and each session costs one extra gpt-5.6-luna turn. Measured on adapter 1.13.1 and 2.2.2.

Change

• New per-agent opt-in rename_new_sessions (default false). Validation accepts true only when cmd has the file name codex-acp.
• When it is on, the mint sends /rename <name> once, after mode/model/effort settle and before the session id is published. The adapter answers this locally with no model turn, and an explicitly named session skips title generation.
• The rename is best effort: one attempt bounded at 5 s, after which the mint publishes the same session whatever happened. No retry, no cancel, nothing added to prompt_inner.
• The catalog/model probe never renames.
• rename_new_sessions joins the frozen provider-effect digest only when true, so existing persisted identities keep their digest.
• No wire, journal, agent-card or persisted-enum change.
• Docs: README.md, docs/onboarding.md, docs/compatibility.md (accepted limits R1–R5), CHANGELOG.md.

Accepted limits (documented)

R1 a wrapper with another file name cannot opt in; R2 tied to the tested adapter versions' /rename; R3 a never-prompted session is still renamed; R4 on timeout the adapter may still be handling the rename; R5 output from a rename that was not answered within the bound may reach the first turn.

Review

• Three review rounds rejected the first commit over the unanswered-rename policy. The spec contradicted itself on that point.
• The owner resolved it with a contract amendment: one bounded attempt, R5 accepted, flag in the digest only when true. The second commit implements the amendment.
• One independent Sol/xhigh review of the combined diff then returned APPROVE.
• Deferred, immaterial: if the connection is fenced while the rename is outstanding and the adapter then answers successfully, the trace event is acp.session_rename_acknowledged (debug) instead of acp.session_rename_interrupted (warn). Logging only; the published session and the close contract are unaffected.

Verification

• Local verification was scoped to the touched crates, per this repo's standing rule: cargo fmt --all -- --check, clippy -D warnings, and cargo test for bridge-acp, bridge-core, bridge-container, bridge-registry, bridge-workflow and a2a-bridge. All passed on macOS with 0 failures.
• The full workspace suite is this PR's CI.
• New behaviour has fail-first tests: ordering, default off, rejection, timeout, a late answer, update suppression, naming, release during the exchange, fence outcomes, config validation and propagation, and the digest (legacy golden values plus both reload directions).
• Not yet verified: a live adapter turn. One fixed PONG against the operator serve follows the merge.

🤖 Generated with Claude Code

https://claude.ai/code/session_017izEynabPeSUBT573AtvaZ

[shoedog]

CI failure on the first push: cli_tests::serving_configs_carry_the_entrys_rename_new_sessions passed a bare cmd = "codex-acp" to acp_spawn_inputs, which resolves the packaged wrapper's binary on PATH; the runner has no codex-acp (ConfigInvalid: codex-acp wrapper could not resolve "codex-acp" on PATH). Reproduced on macOS by removing it from PATH (same message), passes with it. Test-only fix: absolute cmd with the same file name. Re-verified locally: that test with PATH=/usr/bin:/bin, and the full a2a-bridge bin target (1120 passed), fmt, clippy.