Claude Code e GitLab: cosa funziona davvero e dove si ferma

Il supporto GitLab di Claude Code è l'insieme di funzioni che permettono all'agente di lavorare su un repository ospitato su GitLab senza passare da GitHub. Per chi costruisce prodotti in Italia non è un dettaglio di nicchia, perché una quota consistente del codice aziendale sta su istanze GitLab, spesso self-hosted dietro una VPN. Il changelog ufficiale di Claude Code lo tocca in due versioni consecutive, la 2.1.232 del 13 agosto 2026 e la 2.1.233 del 14 agosto 2026, e vale la pena leggerle insieme perché separate dicono poco.

La cosa interessante non è la singola voce, è la direzione. Fino a ieri il modo corretto di descrivere Claude Code su un repository GitLab era "gira lo stesso, ma tutto quello che sa di piattaforma lo sa di GitHub". Adesso quella frase va corretta in tre punti precisi, e restano precise anche le cose che non copre.

Cosa fa Claude Code su GitLab dalla 2.1.233

La voce concreta della 2.1.233 è il supporto agli URL delle merge request di GitLab in due posti: il flag --worktree e la vista claude agents, dove le merge request vengono mostrate nella forma !N. Chi conosce GitLab riconosce la notazione, che è quella della piattaforma per distinguere le merge request dalle issue. Tradotto in pratica, si può incollare l'URL di una merge request dove prima passava solo un URL di pull request, e l'agente parte da lì con il proprio worktree isolato.

Sembra poco e invece è il pezzo che sbloccava tutto il resto. Un agente di coding diventa utile quando riesce ad agganciarsi all'unità di lavoro che il team usa già: se il team ragiona per merge request e lo strumento capisce solo le pull request, ogni sessione comincia con una traduzione manuale fatta da una persona. È lo stesso motivo per cui l'isolamento in worktree dei subagent è stato un passaggio importante: non aggiunge intelligenza al modello, toglie attrito attorno al modello.

Nella stessa versione c'è una seconda voce che dice qualcosa sul confine. Il suggerimento di configurazione della GitHub app adesso non compare più nei repository il cui remote di origine sta su gitlab.com o su bitbucket.org, mentre il suggerimento sul marketplace enterprise copre gli host git interni non GitHub. Claude Code, cioè, ha smesso di trattare GitHub come l'unico posto plausibile in cui può stare il vostro codice.

Perché la parte sui token conta più della merge request

La voce della 2.1.232 che ha più conseguenze pratiche non riguarda il flusso di lavoro ma i segreti. Il changelog di Claude Code elenca la redazione per nove famiglie di token GitLab, glrt-, gloas-, glptt-, glagent-, glimt-, glsoat-, glcbt-, glft- e glffct-, più la redazione completa dei token instradabili glpat- e gldt-. Nella stessa versione lo store di configurazione della CLI glab riceve la stessa protezione di sandbox e di percorso credenziali che gh aveva già.

Questa è la differenza fra "si può usare" e "si può usare in azienda". Un agente che legge il filesystem e scrive nel terminale attraversa continuamente posti dove un token personale può finire in chiaro dentro un log o dentro un transcript. Finché la protezione copriva solo i prefissi GitHub, una squadra su GitLab aveva lo stesso strumento con metà delle garanzie, e quella metà era esattamente quella che il responsabile della sicurezza chiede di vedere per iscritto. Sul rapporto fra agenti e credenziali ho scritto più in dettaglio nell'articolo sui permessi da dare a un'AI che lavora in azienda, e il criterio lì vale identico qui.

Sempre nella 2.1.232 i marketplace di plugin accettano URL di repository gitlab.com nella forma semplice, sottogruppi annidati inclusi, clonandoli come già facevano con github.com, e i messaggi di errore di autenticazione sulla clonazione adesso nominano l'host git reale invece di parlare genericamente. Per chi distribuisce skill e plugin interni al proprio team questo è il punto in cui una libreria condivisa smette di richiedere un account GitHub a tutta l'azienda.

Dove il supporto GitLab si ferma

Le voci di changelog descrivono funzioni puntuali, e conviene leggerle per quello che dicono invece che per quello che lasciano sperare. Gli URL delle merge request sono supportati in --worktree e nella vista claude agents, non genericamente ovunque. La clonazione dei marketplace è documentata su gitlab.com, mentre per gli host git interni la 2.1.233 parla del suggerimento sul marketplace enterprise, che è una cosa diversa dal garantire che ogni istanza self-hosted si comporti come il servizio pubblico.

La regola che uso io quando leggo un changelog è di trattare ogni voce come un contratto sul caso descritto e su nessun altro. Costa qualche prova in più il primo giorno e fa risparmiare la giornata in cui si scopre che la funzione c'era ma non nel posto in cui serviva.

Vale la pena aggiungere che la 2.1.233 chiude anche un problema di sicurezza che tocca soprattutto le squadre su Windows, cioè quelle dove il GitLab aziendale convive con l'autenticazione integrata: i percorsi Windows scritti con il prefisso di dispositivo NT \??\ aggiravano la validazione dei percorsi UNC, e il changelog descrive la correzione come chiusura di un vettore di fuga di credenziali NTLM. Se avete Claude Code su postazioni Windows aziendali, questa da sola giustifica l'aggiornamento.

Cosa fare adesso se il vostro codice sta su GitLab

Da queste due versioni discendono quattro cose concrete, tutte verificabili in pochi minuti.

1. Aggiornate almeno alla 2.1.233 se volete passare URL di merge request al flag --worktree. Sotto quella versione l'URL non viene riconosciuto e non c'è una configurazione che lo aggiri.
2. Controllate che i token GitLab in uso siano fra quelli coperti. La redazione riguarda i prefissi elencati nella 2.1.232, quindi un token generato con uno schema diverso o un token di un'istanza self-hosted con prefisso personalizzato va verificato invece che dato per protetto.
3. Se distribuite plugin interni, provate la clonazione del marketplace dal vostro host prima di annunciarla al team, e usate gli alias additionalMarketplaces e allowedMarketplaces introdotti nella 2.1.232, che il changelog descrive come nomi più leggibili per extraKnownMarketplaces e strictKnownMarketplaces.
4. Su Linux, se una build può mangiarsi la macchina, la 2.1.233 introduce CLAUDE_CODE_TOOL_MEMORY_LIMIT, supporto opt-in ai cgroup di memoria per i comandi dello strumento Bash. È opt-in, quindi finché non la impostate il comportamento resta quello di prima.

Su questo punto parto da una posizione onesta: tutto quello che ho automatizzato sta su GitHub. In questo repository ci sono .github/workflows/stato-indice.yml, il job schedulato che controlla ogni mattina cosa Google ha indicizzato, e automazione-blog/cloud-agent/, la cartella con i prompt delle routine che scrivono gli articoli di questo blog mentre io non sono davanti a niente. È un setup che funziona e che non si trasferisce così com'è: nel momento in cui lo stesso schema serve a un cliente con GitLab dietro la VPN, la parte di agente si riusa e la parte di piattaforma va rifatta. Le voci di queste due versioni riducono quella seconda parte, non la azzerano.

La domanda opposta se la pone chi valuta di spostare il repository dentro il fornitore invece che fuori, ed è quella che apre Cursor mettendo l'hosting del codice dentro il proprio editor: i criteri per decidere stanno in quando conviene tenere il codice dentro lo strumento che lo scrive.

Chi vuole vedere come si imposta il resto della configurazione prima di arrivare qui trova il percorso completo nella guida su come configurare Claude Code, mentre i controlli da fare quando l'agente gira senza nessuno davanti stanno nell'articolo su come far girare Claude Code in automatico.

C'è un'ultima voce della 2.1.233 che non c'entra con GitLab ma che noterete prima di tutte le altre: gli strumenti di tracciamento delle attività, cioè TaskCreate, TaskGet, TaskUpdate, TaskList e TodoWrite, non sono più disponibili su Opus 4.8, Sonnet 5, Fable 5, Mythos 5 e sui modelli successivi. Si riattivano con CLAUDE_CODE_ENABLE_TODO_TOOLS=1. Se avete un flusso che si appoggia alla lista di todo per capire a che punto è l'agente, quella variabile è la riga da aggiungere oggi.

La lettura d'insieme è che Anthropic sta smontando l'assunto che chi usa Claude Code stia su GitHub. Lo sta facendo nel modo lento e poco spettacolare in cui si smontano gli assunti veri, cioè un URL riconosciuto, un prefisso di token aggiunto alla lista, un messaggio di errore che nomina l'host giusto. Non è la notizia che gira, ed è quella che decide se domani potete proporre un agente di coding a un'azienda che il proprio codice non lo ha mai messo su GitHub.

La fonte di tutti i fatti qui sopra è il changelog ufficiale di Claude Code, voci 2.1.232 del 13 agosto 2026 e 2.1.233 del 14 agosto 2026.