# ACP di Zed, Oh My Pi e Pi

_Verifica effettuata il 7 settembre 2026 su documentazione e codice sorgente primari._

## In breve

ACP (Agent Client Protocol) è un protocollo aperto che standardizza il collegamento tra un
editor/IDE e un coding agent. Il paragone utile è con LSP: LSP standardizza editor ↔ language
server, ACP standardizza editor ↔ agente. Il client (per esempio Zed) ospita l'interfaccia;
l'agent process conserva normalmente runtime, modelli, autenticazione, strumenti e configurazione.

ACP usa JSON-RPC 2.0. Copre inizializzazione e autenticazione, creazione/ripristino delle sessioni,
prompt e cancellazione, streaming di testo e pensieri, piani e tool call, comandi, richieste di
permesso e — se entrambe le parti lo supportano — operazioni su filesystem e terminale.

Fonti: [introduzione ACP](https://agentclientprotocol.com/overview/introduction),
[flusso e metodi del protocollo](https://agentclientprotocol.com/protocol/overview),
[External Agents in Zed](https://zed.dev/docs/ai/external-agents).

## Confronto in Zed

| Aspetto | Oh My Pi | Pi |
|---|---|---|
| Tipo di integrazione | Server ACP incorporato: `omp acp` | Adapter comunitario `pi-acp`, installabile dal registry di Zed |
| Collegamento al motore | ACP è una modalità dello stesso motore OMP | L'adapter avvia `pi --mode rpc` e traduce RPC ↔ ACP |
| Output e tool call | Streaming e tool call ACP nativi | Streaming, tool card, posizioni nei file e diff strutturati tradotti dall'adapter |
| File | Può inoltrare `read`/`write` al filesystem del client | Nessuna delega ACP `fs/*`; Pi legge e scrive localmente |
| Terminale | Può creare e seguire terminali del client | Nessuna delega ACP `terminal/*`; i comandi girano localmente |
| Permessi | `edit` e `bash` possono usare `session/request_permission` nell'editor | La UI riceve i tool call, ma non ha la stessa integrazione nativa di file/terminale |
| Sessioni | Implementazione diretta di sessioni, comandi e configurazione ACP | Mappa le sessioni ACP ai file di sessione Pi e supporta `session/load` |
| Skills/comandi | Carica skills, estensioni e slash command OMP | Carica skills e comandi Pi; l'adapter aggiunge comandi per l'uso headless |
| MCP configurati in Zed | OMP contiene il plumbing ACP/MCP nel proprio server | Accettati nei parametri ACP ma non inoltrati a Pi dall'adapter corrente |
| Maturità dichiarata | Funzionalità first-class del progetto | L'adapter si definisce “MVP-style” e centrato soprattutto su Zed |

L'integrazione OMP non è solo una dichiarazione nel README: il comando ACP è parte del sorgente e
il `ClientBridge` instrada `read`, `write`, `bash`, `edit` e richieste di permesso verso il client
quando Zed annuncia le capacità corrispondenti. Fonti:
[README OMP](https://github.com/can1357/oh-my-pi/blob/daf07999c2fee9b22edc7bf8fea1fb6272e0df5e/README.md),
[comando ACP](https://github.com/can1357/oh-my-pi/blob/daf07999c2fee9b22edc7bf8fea1fb6272e0df5e/packages/coding-agent/src/commands/acp.ts),
[ACP ClientBridge](https://github.com/can1357/oh-my-pi/blob/daf07999c2fee9b22edc7bf8fea1fb6272e0df5e/packages/coding-agent/src/modes/acp/acp-client-bridge.ts).

Pi è comunque supportato esplicitamente da Zed: si installa `pi ACP` dal registry. L'integrazione
è però un progetto separato e non una modalità presente nel core Pi. L'adapter corrente conserva
molto dell'esperienza utile — streaming, tool call, diff, resume, comandi e skills — ma dichiara
esplicitamente di non delegare filesystem o terminale a Zed e di non collegare a Pi gli MCP server
ricevuti dal client. Fonti:
[scheda Pi nel registry Zed](https://zed.dev/acp/agent/pi),
[manifest del registry](https://github.com/agentclientprotocol/registry/blob/9ec416a76f69c9ff8a8316931e38f4c74ad41fa8/pi-acp/agent.json),
[README e limiti di `pi-acp`](https://github.com/svkozak/pi-acp/blob/d1cffc047ab37a096ee70ca39cfc1de463db8d12/README.md),
[RPC di Pi](https://github.com/earendil-works/pi/blob/9211da172325117dc59e6f9f25f248dc628b3f81/packages/coding-agent/docs/rpc.md).

## Giudizio

**OMP si trova meglio con ACP perché ACP è una sua interfaccia nativa e il suo livello strumenti è
stato progettato per delegare operazioni all'editor.** Zed non è soltanto una finestra per la chat:
partecipa a file, terminale e autorizzazioni.

**Pi si trova comunque bene con Zed per l'uso quotidiano**, specialmente per conversazione,
streaming, modifiche, diff e ripresa delle sessioni. Oggi, però, l'integrazione è meno profonda:
Zed controlla un adapter che controlla Pi via RPC, mentre file e shell rimangono dal lato Pi.

Per Pi+Amos, i subagenti tmux non diventano automaticamente thread/subagenti nativi di Zed: ACP
espone la sessione Pi principale, mentre l'orchestrazione Amos continua nel proprio runtime e nei
pane tmux. È quindi una combinazione possibile, ma per osservare e pilotare direttamente quei pane
l'esperienza terminale/tmux resta più fedele. Questa conclusione è un'inferenza dall'architettura
dell'adapter (`pi-acp` avvia una singola sessione Pi RPC per sessione ACP) e dai limiti dichiarati,
non una garanzia esplicita del progetto Amos.