Una chiave API salvata come variabile in un ambiente Codex Cloud arriva in chiaro a ogni programma che gira nella VM: i test, gli script di build, le dipendenze appena installate e l’agente stesso. Dal 29 settembre 2026 quell’ambiente non è più pensato come una sandbox usa e getta. Al DevDay OpenAI ha reso gli ambienti cloud di Codex riutilizzabili tra computer, telefono e cloud, pensati, come riporta TechCrunch, per dare ai team uno spazio di lavoro condiviso con impostazioni e permessi approvati. Per chi sviluppa plugin e temi WordPress la domanda pratica diventa una sola: la credenziale dello staging dove la metto?

Variabile o network secret: cosa vede il codice

La guida agli ambienti cloud offre due caselle, e la differenza sta tutta in chi riceve il valore. Una variabile d’ambiente viene passata direttamente ai programmi dell’ambiente: basta un printenv in uno script qualsiasi e la chiave può finire nel log del task. Un network secret invece ha tre campi, Key, Value e Allowed domains. I programmi ricevono un segnaposto, e il proxy dell’ambiente sostituisce il valore vero solo nelle richieste HTTPS sulla porta 443 verso i domini ammessi, sia durante il setup sia durante i task. La documentazione è esplicita: la credenziale grezza non finisce in nessun processo locale e in nessun file.

Per un agente che legge codice scritto da altri, dipendenze comprese, cambia il danno possibile. Con la variabile, la chiave vale ovunque la VM riesca ad arrivare. Con il network secret, vale solo verso l’host che hai scelto tu, e chi la legge dall’interno trova un segnaposto che fuori da quel percorso non serve a niente.

La configurazione per un plugin WordPress

Si parte da Work in > Cloud > Select environment > Create environment, sul web o nell’app desktop. Scegli il repository GitHub del plugin: GitLab e GitHub Enterprise Server self-hosted oggi non sono supportati. Codex ispeziona il repository, installa dipendenze e strumenti, prova il flusso e ti chiede quello che non riesce a dedurre da solo.

Poi la rete. Attiva Allow Codex to access internet e scegli il preset Package managers. Qui c’è la trappola per chi lavora in PHP: il preset copre, tra gli altri, npm, Yarn, PyPI, GitHub e i repository Ubuntu e Debian, ma nell’elenco pubblicato non compare Packagist. Se il plugin usa Composer, aggiungi repo.packagist.org sotto Additional allowed domains, e se composer install fallisce ancora leggi il nome host nell’errore e aggiungi quello. Aggiungi anche il dominio dello staging.

Terzo passo, le credenziali: un network secret per il token dello staging, con il solo dominio dello staging tra quelli ammessi. Salvarlo aggiunge da solo quella destinazione all’accesso internet ristretto. Le variabili restano per i valori innocui, come WP_ENV=staging. Infine Publish, e un task nuovo per provare: i task già aperti tengono il loro stato e non vedono le modifiche.

L’errore da evitare: ripiegare sulla variabile

La stessa guida indica la via di fuga: se il programma deve leggere il valore grezzo, mettilo tra le variabili d’ambiente. È la scorciatoia che si prende alla prima chiamata che fallisce, e con WordPress può capitare presto. Le Application Password della REST API passano in Basic Auth, cioè il client codifica in base64 la coppia utente e password prima di spedirla. La documentazione di Codex non dice se il proxy riconosce il segnaposto anche dentro un valore codificato: va provato durante il setup, con una chiamata autenticata allo staging, prima di pubblicare l’ambiente.

Se la prova non passa, la risposta non è la variabile con la password di produzione. Crea sullo staging un utente dedicato con il ruolo più basso che basta al lavoro, generagli una Application Password che puoi revocare in un clic e usa quella. Se poi condividi l’ambiente con il workspace, la guida chiede di rivedere prima i file preparati e le credenziali di proprietà dell’ambiente. I valori di ciascuno vanno nel Personal vault: condividere l’ambiente condivide i requisiti, non le credenziali personali.

La mia regola: la VM vede solo lo staging

Tratto un ambiente Codex Cloud come tratterei un collaboratore esterno appena arrivato: accesso al repository, a uno staging con dati finti e a nient’altro. Non è sfiducia nel modello. È che un ambiente riutilizzabile e condiviso vive più a lungo del task che l’ha creato, e lo stato salvato di un task resta recuperabile, di default, fino a sette giorni dall’ultimo turno o ripresa. Una credenziale di produzione dentro quella VM è una credenziale di cui diventa difficile sapere chi può usarla, e da quale dispositivo.

Il resto della sicurezza lo fanno i limiti già documentati. La connessione VPN verso la rete privata, oggi solo Tailscale, raggiunge solo servizi HTTP e HTTPS e non supporta SSH né i protocolli nativi dei database: il server interno del cliente non diventa un terminale aperto per l’agente. Per chi arriva a Codex dal lato organizzativo, il caso Proaction sulle PMI spiega il workflow. Per il lato chiavi dentro WordPress, il confronto tra chiave nel sito e proxy server-side segue la stessa logica.

Prima di premere Publish, tre controlli: nessun valore segreto tra le variabili d’ambiente, ogni network secret legato a un solo dominio, una chiamata autenticata allo staging riuscita in un task nuovo. Se uno dei tre manca, l’ambiente resta in bozza.