Summary
codex-acp advertises and handles a subset of Codex CLI slash commands, but /new (start a fresh conversation) is not among them. Clients that forward slash-command text to the agent get no reset: the command falls through to the "unknown command" path and the conversation continues on the same thread.
Details
getBuiltinCommands() advertises: mcp, skills, status, review, review-branch, review-commit, compact, goal, logout. tryHandleCommand() switches on those and sends any other /xxx to sendUnknownCommandMessage(...) (the default arm), returning { handled: true }.
/new is a documented Codex CLI slash command (https://developers.openai.com/codex/cli/slash-commands/), and the same doc is cited in getBuiltinCommands, but the reset command itself is not implemented. So /new is swallowed as unknown and the Codex conversation keeps its full prior context.
Version observed: @agentclientprotocol/codex-acp 1.1.2.
Impact
ACP clients that recognize /new as Codex's reset shortcut and forward it as prompt text render a "conversation cleared" state on their side, but the model still remembers everything and token/context accounting never drops. There is no working reset path short of tearing down and re-creating the ACP session.
Request
Implement /new as a builtin command that starts a fresh Codex conversation on the current ACP session (the adapter already exposes session/new; the reset primitive exists). Concretely:
- Add
new to getBuiltinCommands() so it appears in available_commands_update.
- Handle it in
tryHandleCommand() by resetting the underlying Codex thread/conversation for the session, so subsequent prompts start with no prior context.
That makes /new behave over ACP the way claude-agent-acp handles /clear (local reset without forwarding to the model).
Alternatives considered
- Clients can call
session/new themselves for a hard reset, but that splits onto a new session id and loses the client's stable session mapping; a native /new reset on the existing session is the cleaner parity with the Codex CLI and with other ACP adapters.
Summary
codex-acpadvertises and handles a subset of Codex CLI slash commands, but/new(start a fresh conversation) is not among them. Clients that forward slash-command text to the agent get no reset: the command falls through to the "unknown command" path and the conversation continues on the same thread.Details
getBuiltinCommands()advertises:mcp,skills,status,review,review-branch,review-commit,compact,goal,logout.tryHandleCommand()switches on those and sends any other/xxxtosendUnknownCommandMessage(...)(thedefaultarm), returning{ handled: true }./newis a documented Codex CLI slash command (https://developers.openai.com/codex/cli/slash-commands/), and the same doc is cited ingetBuiltinCommands, but the reset command itself is not implemented. So/newis swallowed as unknown and the Codex conversation keeps its full prior context.Version observed:
@agentclientprotocol/codex-acp1.1.2.Impact
ACP clients that recognize
/newas Codex's reset shortcut and forward it as prompt text render a "conversation cleared" state on their side, but the model still remembers everything and token/context accounting never drops. There is no working reset path short of tearing down and re-creating the ACP session.Request
Implement
/newas a builtin command that starts a fresh Codex conversation on the current ACP session (the adapter already exposessession/new; the reset primitive exists). Concretely:newtogetBuiltinCommands()so it appears inavailable_commands_update.tryHandleCommand()by resetting the underlying Codex thread/conversation for the session, so subsequent prompts start with no prior context.That makes
/newbehave over ACP the wayclaude-agent-acphandles/clear(local reset without forwarding to the model).Alternatives considered
session/newthemselves for a hard reset, but that splits onto a new session id and loses the client's stable session mapping; a native/newreset on the existing session is the cleaner parity with the Codex CLI and with other ACP adapters.