Feature: publish a versioned ACP/host protocol for IDE and orchestration integrations

Goal

I am preparing a Command Code integration for T3 Code and would prefer a supported public boundary rather than terminal parsing, project settings, or experimental Mods.

The existing headless NDJSON mode is already a strong one-way event/result stream. The missing piece for first-class IDE/orchestrator integrations is a bidirectional local host protocol: permissions, structured user input, cancellation, durable sessions, model discovery, capability negotiation, and attachment support.

Proposal

Publish a long-lived local stdio mode, for example:

command-code acp

It would implement ACP v1 over JSON-RPC and advertise a capability-gated commandcode.profile/v1 for Command Code-specific behavior.

The public contract should include:

• protocol-version and capability handshake;
• create/resume/fork/rollback/cancel session lifecycle with opaque stable IDs;
• ordered session/turn/tool/subagent events with correlation IDs and sequence numbers;
• request/response permissions before every gated side effect, including MCP tools;
• structured ask_user_question responses;
• JSON model discovery, model selection, modes, typed safe errors, and image attachments;
• a published schema/types package, plus black-box conformance fixtures.

Permission bridge: reuse the existing engine

The request is not to create a parallel security model.

The public host boundary should abstract the existing “ask” prompt behind a native PermissionDecisionProvider / PermissionPromptBridge, with two implementations:

• the existing TUI prompt;
• an ACP/host implementation.

The required decision flow is:

1. local hard-deny and safety rules remain authoritative;
2. locally pre-approved actions proceed normally;
3. only an unresolved ask is emitted to the host as a correlated permission request;
4. the host returns one of the offered decisions (allow once, scoped session allow when supported, deny, cancel);
5. timeout, disconnect, malformed response, stale/duplicate request ID, or cancellation denies the pending action.

In other words, host mode should behave like the existing fail-closed dont-ask policy plus an external, structured channel for the unresolved ask outcome. It must not write project settings or let a host override local deny rules.

This ask-routing must be native machinery: the current Mod API can add tools, hooks, and observers, but does not document interception of the underlying permission decision itself.

Security expectations

• A lost connection, timeout, malformed response, stale request ID, or cancellation must deny the pending action and emit one terminal result.
• Existing local deny rules remain authoritative.
• A session-level approval is in-memory and scoped; it must not write project settings.
• The protocol is local stdio only: no network listener and no credentials from an external orchestrator client.

This would let T3, IDEs, CI systems, and other clients integrate against a versioned contract while preserving the interactive TUI, Hooks, and Mods as separate local extension surfaces.

I can help validate the protocol with an independent T3 adapter and conformance suite when the source is available.

Would the team prefer:

1. ACP v1 + a Command Code capability profile;
2. a Command Code-specific stdio protocol with equivalent guarantees; or
3. both, sharing one public schema layer?

Bắt đầu bằng cách kiểm tra entry point NDJSON headless hiện có và lời nhắc quyền hiện tại của TUI, sau đó so sánh chúng với entry point command-code acp được đề xuất và PermissionDecisionProvider/PermissionPromptBridge. Công việc được xem là hoàn tất khi nhóm đã chọn hướng đi cho protocol và xác định các yêu cầu về handshake có phiên bản, session, permission, error, schema và conformance; issue không xác định file triển khai hoặc test nào.