Se il codice sorgente di un progetto commerciale non può essere inviato a un modello cloud, che cosa posso ancora fare con ChatGPT sul web? Può controllare lo stato del progetto locale o richiedere una verifica SSH controllata? E se il codice può essere ospitato, perché usare un MCP locale?

La scelta non riguarda un singolo strumento. Conta che cosa lo strumento può vedere, dove viene eseguito il lavoro e dove torna il risultato.

In breve: l’app web non legge automaticamente il tuo Mac. Se non fornisci il codice al modello, può dare consigli basati su riepiloghi o stati condivisi esplicitamente, ma non può esaminare o fare debug in autonomia di codice che non ha visto.

Eseguire Codex in locale non significa che anche l’inferenza sia locale. Codex Cloud non è una connessione al tuo Mac. Un tunnel MCP inoltra le richieste, ma non limita da solo i permessi degli strumenti. GitHub Private controlla l’accesso al repository; non rende locale un repository ospitato. Se il codice viene fornito a un modello cloud, quel contesto entra nel suo perimetro di elaborazione. Di seguito confronto i percorsi e due esempi pubblici: VXI Local-First MCP e VXI SSH Ops Bridge. Il primo condivide solo lo stato del progetto locale; il secondo permette esclusivamente un’operazione SSH in sola lettura, definita in anticipo.

Confrontare i percorsi: dove si trova il workspace e che cosa vede il modello?

Percorso	Workspace e posizione di esecuzione	Che cosa può vedere il modello cloud	Uso adatto
Codex Local environment desktop + MCP locale	Progetto/worktree, terminale e processo MCP sul Mac	Dipende dal contesto realmente inviato al modello; esecuzione locale non significa inferenza locale	Leggere/scrivere file, eseguire comandi e controllare diff entro i permessi concessi, dopo aver verificato il confine dei dati del modello
Codex Cloud / attività cloud dal web	Repository GitHub selezionato in un workspace cloud isolato	Codice sorgente e file accessibili all’attività	Modificare codice, eseguire controlli e consegnare un branch o un risultato quando l’uso di GitHub e del cloud è autorizzato
Coding Agent cloud di GitHub	Repository e ambiente temporaneo dell’agent nel cloud	File del repository, contesto dell’attività e contenuti accessibili durante l’esecuzione	Collaborazione tramite branch, PR e controlli
ChatGPT Web + Secure MCP Tunnel + Local-First MCP	MCP eseguito localmente; il dispositivo avvia un tunnel in uscita	Solo conteggi e stati esplicitamente restituiti dall’MCP	Condividere metadati limitati senza concedere lettura del codice o accesso Shell
ChatGPT Web + Secure MCP Tunnel + SSH Ops Bridge	Bridge MCP locale e client SSH collegati a un host configurato	Alias del target e risultato filtrato di un controllo fisso	Richiedere un controllo in sola lettura consentito su un target non di produzione
Modello web + relay locale per coding-agent (da costruire a parte)	Un adattatore locale delega a Codex o a un altro coding agent locale	Dipende dalla posizione dell’inferenza e da ciò che l’adattatore restituisce	Possibile architettura futura, ma richiede controlli propri su strumenti, output, scritture, timeout e approvazione umana

Una limitazione importante: la configurazione del tunnel qui descritta si basa sulla documentazione ufficiale OpenAI, ma l’autore non ha ancora verificato sul proprio Mac reale la connessione end-to-end tra ChatGPT Web e l’MCP locale. È un riferimento di configurazione, non una procedura one-click già verificata.

Scegliere il percorso prima di configurarlo

• Il codice non può mai essere inviato a un modello cloud: mantieni il lavoro sul codice nell’inferenza locale o in un altro flusso locale affidabile. Un MCP di soli metadati può condividere stati approvati, ma un modello cloud che non vede il codice non può esaminarlo in modo indipendente.
• Vuoi solo che ChatGPT Web veda lo stato locale: usa una proiezione a campi fissi come Local-First MCP; non richiede accesso in lettura al codice né Shell.
• Vuoi chiedere dal web un controllo SSH fisso: usa un’operazione nominata come SSH Ops Bridge e conserva localmente identità dell’host, chiavi private e allowlist dei target.
• Il codice può essere ospitato e vuoi che l’IA lo legga e lo modifichi: usa GitHub-first, Codex Cloud o un altro agent cloud autorizzato, lasciando branch, PR, commit e CI come prove verificabili.
• Vuoi che l’IA web deleghi lavoro di codice a Codex locale: serve costruire e revisionare un relay locale per agent separato. Né l’MCP di metadati né il bridge SSH forniscono questa capacità.
• I progetti hanno classificazioni dei dati diverse: scegli il percorso per ciascun progetto. Poter ospitare il repository del blog non significa poter inviare codice commerciale attraverso lo stesso percorso.

Gli strumenti web di altri fornitori vanno verificati uno per uno: controlla il percorso MCP remoto o agent locale supportato, l’autenticazione, le capacità dell’agent locale e gli input e risultati degli strumenti che raggiungono davvero il modello. Il solo supporto MCP non significa che Secure MCP Tunnel di OpenAI sia riutilizzabile senza modifiche.

Riferimenti ufficiali: Codex Local environments, Codex Cloud environments, Codex MCP, OpenAI Secure MCP Tunnel e GitHub Copilot cloud agent.

Tre flussi di dati

A. L’IA web legge lo stato del progetto locale

ChatGPT Web
    |
OpenAI Secure MCP Tunnel endpoint
    ^ il tunnel-client locale avvia HTTPS in uscita
    |
vxi-local-first-mcp locale (stdio MCP)
    |
directory locale: conta le voci senza leggere il contenuto del codice

Restituisce: conteggi + PASS / FAIL / UNKNOWN
Non restituisce: codice, percorsi, diff, log, comandi

B. L’IA web richiede un controllo SSH fisso

ChatGPT Web
    |
OpenAI Secure MCP Tunnel endpoint
    ^ il tunnel-client locale avvia HTTPS in uscita
    |
vxi-ssh-ops-bridge locale (stdio MCP)
    |
client SSH locale + chiave privata + pinned known_hosts
    |
target SSH non di produzione: script fisso in sola lettura
    |
stati filtrati health / service / storage
    |
risposta all'app web

C. Sviluppo cloud GitHub-first

Repository GitHub autorizzato all'hosting
    |
Codex Cloud / agent cloud di GitHub
    |
workspace cloud legge il codice, modifica file ed esegue controlli
    |
branch + PR + commit + CI
    |
revisione e approvazione umana

Sono modelli operativi diversi. I primi due limitano ciò che uno strumento web può vedere o richiedere. Il terzo consente all’IA di svolgere sviluppo a livello di codice in un workspace cloud autorizzato.

Non confondere Codex Local, Codex Cloud e MCP

Codex Local environment nell’app desktop configura passaggi di preparazione e azioni frequenti per un progetto locale o un worktree. Il terminale integrato esegue comandi localmente; gli strumenti Git possono controllare diff, fare stage, commit, push e creare PR. Un client Codex locale può anche avviare un server MCP locale via stdio: è un host MCP locale che avvia un server locale e non richiede un tunnel web.

Ma «esecuzione locale» indica solo dove girano file e comandi. Se il modello è ospitato, il contesto del codice usato per l’analisi può comunque essere inviato al cloud. Per impedire rigorosamente l’uscita del codice servono inferenza locale o un flusso locale affidabile e verificato, oltre a un audit separato degli altri processi e percorsi di rete del dispositivo.

Codex Cloud colloca invece il repository GitHub selezionato in un workspace cloud isolato, prepara le dipendenze ed esegue le attività lì. Gli agent cloud di GitHub possono leggere il codice, modificare branch, eseguire controlli e creare PR in ambienti cloud. È adatto ai progetti autorizzati a superare quel confine, non sostituisce la necessità di mantenere il codice sul Mac.

Differenza tra MCP host e MCP server

• ChatGPT desktop, Codex CLI ed estensioni IDE come MCP host: possono avviare server stdio locali secondo la configurazione supportata dal client. La forma ufficiale del CLI è:

codex mcp add vxi-local-status \
  --env "VXI_WORKSPACE=/absolute/path/to/project" \
  -- /absolute/path/to/node /absolute/path/to/vxi-local-first-mcp/bin/vxi-local.mjs mcp

codex mcp list

Per SSH Ops Bridge usa lo stesso schema, impostando VXI_OPS_CONFIG sul percorso locale di ops.config.json e puntando il comando server a vxi-ssh-ops-bridge/bin/vxi-ops.mjs. Hostname, account, percorsi delle chiavi private e ops.config.json devono restare locali. Non incollare segreti di runtime nella chat né committarli in Git. L’app desktop, Codex CLI e le estensioni IDE supportate possono usare la configurazione MCP dell’host Codex, nei limiti dei permessi del workspace.

• ChatGPT Web come chiamante: l’app web non legge ~/.codex/config.toml locale e non eredita automaticamente il menu dei comandi di Codex locale. Serve un percorso MCP remoto supportato. Secure MCP Tunnel consente a un client locale di collegarsi in uscita a un endpoint ospitato da OpenAI e inoltrare richieste a un server MCP locale via stdio o HTTP.

Collegare il web a un MCP locale e richiedere SSH

La documentazione OpenAI di Secure MCP Tunnel descrive un tunnel-client eseguito in una rete che può raggiungere il servizio MCP privato. Il client avvia HTTPS in uscita, riceve richieste dall’endpoint ospitato, le inoltra al server MCP locale via stdio o HTTP e restituisce la risposta attraverso lo stesso tunnel. Non serve aprire una porta pubblica in ingresso sul Mac.

I percorsi e gli ID del tunnel qui sotto sono segnaposto. Conserva le credenziali di runtime solo nelle variabili d’ambiente locali.

1. Crea o seleziona un tunnel in OpenAI Platform. Verifica l’associazione tra il workspace ChatGPT e l’organizzazione Platform e il permesso Tunnel necessario.
2. Scarica il tunnel-client corrente dalle impostazioni del tunnel in Platform. Controlla l’help/quickstart aggiornato e configura un profilo separato per ciascun server MCP.
3. Prima di configurare il tunnel, prova offline ogni server MCP. Per Local-First MCP:

cd /path/to/vxi-local-first-mcp
node --version  # >= 22
npm test
npm run demo

Dopo il superamento dei controlli, configura il profilo Local-First:

export CONTROL_PLANE_API_KEY="<runtime-key kept in the local terminal>"

tunnel-client init \
  --sample sample_mcp_stdio_local \
  --profile vxi-local-status \
  --tunnel-id "<your-tunnel-id>" \
  --mcp-command "/usr/bin/env VXI_WORKSPACE=/absolute/path/to/project /absolute/path/to/node /absolute/path/to/vxi-local-first-mcp/bin/vxi-local.mjs mcp"

tunnel-client doctor --profile vxi-local-status --explain
tunnel-client run --profile vxi-local-status

I percorsi assoluti evitano di dipendere dal fatto che un processo in background abbia la stessa directory di lavoro o lo stesso PATH del terminale interattivo.

Per SSH Ops Bridge, esegui prima npm test e npm run demo. Crea ops.config.json locale a partire da ops.config.example.json e cambia mode da disabled a read_only. Configura solo un target non di produzione verificato indipendentemente, un account a basso privilegio, il percorso locale della chiave privata e un file known_hosts fissato. Installa lo script di sola lettura sul server di test in /usr/local/bin/vxi-health-check come indicato nel README. Poi configura un profilo separato:

tunnel-client init \
  --sample sample_mcp_stdio_local \
  --profile vxi-ssh-readonly \
  --tunnel-id "<your-ssh-tunnel-id>" \
  --mcp-command "/usr/bin/env VXI_OPS_CONFIG=/absolute/path/to/ops.config.json /absolute/path/to/node /absolute/path/to/vxi-ssh-ops-bridge/bin/vxi-ops.mjs mcp"

tunnel-client doctor --profile vxi-ssh-readonly --explain
tunnel-client run --profile vxi-ssh-readonly

Le schermate di Platform e le versioni dei client possono cambiare; consulta l’help della versione installata per le opzioni precise.

4. Lascia attivo tunnel-client run. Nell’entry MCP personalizzata supportata da ChatGPT scegli Add custom MCP server → Tunnel, seleziona il tunnel disponibile, autentica la sessione e controlla la richiesta di permessi. Se il tunnel non compare, verifica l’associazione workspace/organizzazione e i permessi invece di rendere pubblico l’MCP locale.
5. Chiama prima vxi_project_status o vxi_ops_policy in sola lettura per confermare che lo strumento venga rilevato; richiedi vxi_ssh_health solo se necessario. Non testare su host di produzione e verifica la chiave SSH attraverso un canale indipendente.

Che cosa fa localmente il bridge SSH

L’amministratore locale salva host, username, porta, percorso della chiave privata e known_hosts verificato indipendentemente in ops.config.json. L’MCP accetta solo alias della allowlist locale, come lab, non stringhe di comando generate dal modello. Il bridge ignora la configurazione SSH personale, disabilita agent forwarding e richieste interattive di password, esegue lo script fisso /usr/local/bin/vxi-health-check e riduce la risposta a tre stati.

L’app web non riceve la chiave privata né accede direttamente al server: richiede un’operazione fissa. Il tunnel trasporta la richiesta, mentre elenco degli strumenti, validazione degli input, configurazione locale, associazione della host key e script remoto definiscono insieme il limite dei permessi.

Se dietro l’MCP si collega un agent locale che può modificare codice, occorre esaminare separatamente strumenti, input, output, scritture di file, esecuzione di comandi, timeout e approvazione umana. La valutazione di sicurezza di un MCP SSH limitato non si applica automaticamente a un relay di coding-agent con permessi di scrittura.

Il ruolo dei due repository pubblici

VXI Local-First MCP: condividere solo metadati del progetto locale

Apri il repository

L’MCP locale via stdio espone due strumenti di sola lettura:

• vxi_project_status: conteggi per categoria di file, numero di symlink ignorati e stati lint/test/build inseriti manualmente (PASS / FAIL / UNKNOWN; il valore iniziale è UNKNOWN). L’MCP non esegue test. La scansione limitata ignora directory nascoste e comuni directory di build/cache come .git, node_modules e dist. Elabora al massimo 20.000 voci di directory; superato il limite, genera un errore invece di restituire conteggi parziali. Non è quindi un inventario completo di ogni possibile file del progetto.
• vxi_security_contract: descrive i campi consentiti e vietati nella risposta.

Lo scanner classifica le voci di directory senza leggere il contenuto dei file sorgente. La proiezione fissa non include codice, percorsi, diff, log, variabili d’ambiente o interfaccia Shell. Permette al modello cloud di vedere uno stato limitato, ma non cifra e carica il codice.

record è un comando CLI locale, non uno strumento MCP, e non esegue test. Esempio:

node bin/vxi-local.mjs record --workspace /path/to/project --kind test --status PASS

kind può essere lint, test o build; lo stato viene inserito dall’operatore. Serve solo a fornire al modello web un contesto approssimativo dei controlli locali senza caricare codice o log grezzi. Non diagnostica un errore e non è una prova di test firmata e associata a un commit. Per il debug, controlla i log completi localmente o condividi un riepilogo minimo dell’errore selezionato e oscurato manualmente.

VXI SSH Ops Bridge: solo operazioni SSH fisse in sola lettura

Apri il repository

Il bridge è disabilitato per impostazione predefinita ed espone solo vxi_ops_policy e vxi_ssh_health. Quest’ultimo accetta un alias dalla allowlist locale, esegue uno script remoto fisso e filtra il risultato negli stati health, service e storage. Il health: PASS dello script di esempio dimostra solo che lo script fisso è stato eseguito; service e storage restano UNKNOWN finché non vengono installati e verificati controlli specifici dell’applicazione. Non offre exec(command) generico, trasferimento di file, deploy, riavvio o esportazione arbitraria di log.

I repository sono indipendenti. Uno condivide lo stato del progetto locale, l’altro permette un solo controllo SSH fisso. Nessuno dei due dispone di strumenti per modificare il codice o chiama l’altro.

Che cosa dimostra davvero un test verde?

I conteggi seguenti si riferiscono a repository e livelli di test diversi; non sono la stessa suite conteggiata più volte:

• Local-First MCP: main contiene 6 test unitari (CI di base). PR #3 aggiunge una matrice Ubuntu/macOS, non nuovi casi; gli stessi sei test passano 6/6 su entrambi i sistemi (CI PR #3).
• SSH Ops Bridge: main contiene 7 test unitari (CI di base). PR #3 mantiene i sette test e aggiunge un job di integrazione OpenSSH localhost separato su un Runner Ubuntu ospitato da GitHub e usato una sola volta. Passano sia i test unitari sia i controlli SSH loopback (CI PR #3).
• SSH Ops Bridge PR #4: aggiunge un caso di test ai sette esistenti per coprire host/user mancanti o di tipo errato, insieme alla relativa validazione di stringa. Sul branch Draft non ancora unito passano 8/8 test unitari e la demo (CI PR #4).

Il fixture loopback ha rivelato problemi reali nel disegno dei test: inizialmente utente Runner e configurazione PAM non coincidevano e l’autenticazione falliva. In seguito è emerso che un ForceCommand sul server poteva sovrascrivere la richiesta del client e generare un falso positivo anche senza eseguire il comando previsto. Dopo la correzione, il fixture non configura ForceCommand: il vero client SSH esegue lo script remoto fisso generato. I test verificano sia le chiamate dirette sia i risultati MCP e rifiutano una pinned host key errata e richieste exec arbitrarie.

Questi risultati valgono solo per le versioni esatte collegate. Al momento della verifica, i tre PR del codice sono ancora Draft e non uniti. La matrice multipiattaforma e il job loopback del PR #3, oltre alla correzione della validazione del PR #4, non fanno ancora parte di main.

Conclusione: scegliere in base al confine dei dati, non al nome dello strumento

Se il codice può entrare nel cloud, GitHub-first permette all’IA di leggerlo e modificarlo e conserva prove di sviluppo verificabili tramite branch, PR, commit e CI. Se il codice deve restare locale, Local-First MCP può condividere lo stato con un modello web e SSH Ops Bridge può offrire una singola operazione remota in sola lettura. Lo sviluppo a livello di codice richiede comunque una persona locale, inferenza locale o un altro flusso locale revisionato.

Il confine da proteggere non è semplicemente «usare uno strumento locale» o «collegare MCP». Conta che cosa ogni percorso invia davvero al modello, quali operazioni il modello può richiedere e dove finisce la risposta.

Entrambi i repository sono ancora prototipi minimi. Il tunnel non è stato verificato sul Mac reale dell’autore; non sono stati testati un host SSH esterno, l’intero dispositivo per l’uscita del codice, una vera inferenza locale né un confronto di qualità, latenza, token e costo sullo stesso compito.