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

Inizia esaminando l’entry point NDJSON headless esistente e il prompt di autorizzazione TUI attuale, quindi confrontali con l’entry point proposto command-code acp e con PermissionDecisionProvider/PermissionPromptBridge. Il lavoro è completato quando il team ha selezionato una direzione per il protocollo e definito i requisiti di handshake versionato, sessione, autorizzazioni, errori, schema e conformità; nell’issue non vengono identificati file di implementazione né test.

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?