Claude Code în cloud: unde rulează, de fapt, agentul tău

Întrebarea pe care nu o pune nimeni înainte de a apăsa Enter: unde rulează, de fapt, sesiunea asta? Pentru Claude Code există astăzi trei răspunsuri diferite — pe mașina ta, pe o mașină virtuală administrată de Anthropic sau pe infrastructura companiei tale — iar diferența dintre ele nu e de confort, ci de unde ajunge codul clientului, cine vede logurile și ce răspunzi la următorul audit. Ghidul de față tratează partea din cloud: cum pornești o sesiune cu --cloud, cum o aduci înapoi în terminal cu /teleport, ce urcă efectiv în mașina virtuală și când are sens să muți execuția pe serverele tale.

Trei locuri, trei modele de risc

O sesiune în terminal sau în IDE rulează întotdeauna pe mașina dezvoltatorului. O sesiune în cloud este, în definiția din documentație, orice sesiune care rulează în altă parte decât pe mașina dezvoltatorului — pornită de la claude.ai, din aplicațiile de mobil și desktop, din terminal cu claude --cloud sau de o rutină programată. Implicit, ea se execută pe infrastructura Anthropic. Dacă organizația ta a configurat un mediu găzduit propriu, aceleași sesiuni rulează în rețeaua ta.

Modelul mental corect nu e „local versus cloud", ci „ce are voie să atingă sesiunea". Restul articolului desface cele trei coloane. Pentru partea de fundament — bucla plan/edit/review, CLAUDE.md ca memorie de proiect, lucrul pe multi-fișier și modul headless — programul complet e cursul Claude Code Mastery: coding agentic din terminal; aici presupunem că ai trecut de instalare și lucrezi deja zilnic cu agentul.

Nu confunda cu Remote Control

Cea mai frecventă confuzie merită lămurită din prima, pentru că cele două funcții sună identic și fac lucruri opuse:

• Remote Control (/remote-control) expune o sesiune care rulează pe mașina ta ca să o poți conduce din browser sau de pe telefon. Codul, fișierele și execuția rămân local.
• Sesiunile în cloud (--cloud) creează o sesiune care rulează în altă parte, pe o mașină virtuală, cu o clonă a repo-ului.

Documentația le separă explicit: --cloud creează sesiuni în cloud, --remote-control nu are legătură cu ele. Dacă ceea ce îți trebuie e să răspunzi la o cerere de permisiune din tramvai, în timp ce migrarea rulează pe laptopul de la birou, ai nevoie de a doua variantă — despre care am scris pe larg în ghidul dedicat Remote Control. Restul acestui articol e despre prima.

Cum pornești o sesiune în cloud, din terminal

Comanda e o singură linie:

claude --cloud "Repară bug-ul de autentificare din src/auth/login.ts"

Ce se întâmplă în spate merită înțeles, pentru că aici apar majoritatea surprizelor: mașina virtuală clonează remote-ul GitHub al directorului curent, pe branch-ul curent — nu checkout-ul tău local. Dacă ai commit-uri nepușate, sesiunea nu le vede. Regula practică: git push înainte de --cloud, mereu.

Câteva detalii care contează în uzul zilnic:

• Funcționează cu un singur repo o dată. Vechea scriere --remote încă merge, ca alias depreciat.
• Fiecare comandă --cloud creează o sesiune independentă, deci poți porni trei sarcini care rulează simultan, în timp ce tu lucrezi mai departe local.
• Le urmărești cu /tasks din CLI sau din lista de sesiuni de la claude.ai, inclusiv din aplicația de mobil.
• Poți trimite un mesaj suplimentar într-o sesiune care deja rulează, de pe orice mașină pe care ești autentificat: claude -p "mesajul tău" --cloud <session-id>. Comanda pune mesajul în coadă și iese, ceea ce o face utilizabilă și dintr-un script de CI.
• Sesiunile în cloud cer un cont Anthropic. Nu sunt disponibile când Claude Code e configurat pe Amazon Bedrock, pe platforma de agenți Google Cloud sau pe alt furnizor terț.

Tiparul cel mai productiv, recomandat chiar de documentație: planifici local, execuți remote. Pornești în mod plan, stabiliți împreună abordarea, salvezi planul în repo, faci push, apoi trimiți execuția în cloud. Agentul primește un plan scris, nu o propoziție.

/teleport: aduci sesiunea înapoi în terminal

Când sesiunea din cloud a ajuns undeva și vrei să continui pe mașina ta, o „teleportezi": claude --teleport deschide un selector de sesiuni, /teleport (sau /tp) face același lucru dintr-o sesiune deja pornită, iar din /tasks ajungi acolo cu tasta t. Claude verifică repo-ul, aduce și face checkout branch-ului din sesiunea de cloud și încarcă tot istoricul conversației în terminal.

Patru condiții trebuie îndeplinite, altfel comanda se oprește:

1. Working directory curat — dacă ai modificări necomise, ți se propune să le pui pe stash.
2. Repo-ul corect — trebuie să rulezi dintr-un checkout al aceluiași repository, nu dintr-un fork.
3. Branch-ul împins pe remote — teleportarea îl aduce de acolo.
4. Același cont — cel cu care a fost pornită sesiunea în cloud.

Două lucruri pe care le înțeleg greșit chiar și utilizatorii experimentați. Primul: --teleport nu e --resume. --resume redeschide o conversație din istoricul local al mașinii; --teleport aduce o sesiune din cloud, împreună cu branch-ul ei. Al doilea: după teleportare, terminalul primește propria copie a sesiunii. Ce faci mai departe rămâne local și nu mai apare în sesiunea din cloud. Dacă vrei să continui să o conduci de pe telefon, pornești /remote-control în sesiunea locală — exact punctul în care cele două funcții se leagă.

Din CLI, transferul e într-un singur sens: poți trage o sesiune din cloud în terminal, dar nu poți împinge o sesiune de terminal în web.

Ce urcă, de fapt, în mașina virtuală

Partea pe care orice responsabil de securitate o va întreba prima. În mod normal, VM-ul clonează din GitHub. Dar există situații în care Claude Code împachetează repo-ul local și îl urcă: când directorul nu are remote git sau când aplicația GitHub a Claude nu e instalată pe acel repository. Ce intră în pachet:

• istoricul complet al repo-ului, pe toate branch-urile;
• modificările necomise la fișierele urmărite;
• nu intră fișierele neurmărite — dacă vrei să fie văzute, le adaugi în git.

Pe macOS, Linux și WSL, modificările necomise la fișiere care arată a credențiale sunt lăsate în afara pachetului, iar Claude Code îți spune ce a exclus: fișiere .env, fișiere Terraform *.tfvars și chei de tip id_rsa sau *.pem. Sesiunea pornește cu versiunea comisă a fiecăruia sau fără fișier, dacă nu există niciuna. Excepția care merită ținută minte: într-un worktree legat sau într-un submodul, aceste modificări se urcă, iar Claude Code numește fișierele pe care le-a inclus. Pachetul trebuie să stea sub 100 MB, cu degradări succesive pentru repo-uri mai mari.

Concluzia operațională e simplă: dacă politica firmei spune că un anumit cod nu părăsește rețeaua, --cloud nu e o comandă pe care o lași la discreția fiecărui dezvoltator. E o decizie de politică, la același nivel cu regulile despre ce date intră în unelte AI — subiect tratat cap-coadă în cursul Politică de utilizare AI și securitatea datelor în companie.

Izolare, rețea și credențiale

Documentația descrie patru straturi de separare pentru sesiunile găzduite de Anthropic:

• Mașini virtuale izolate — fiecare sesiune într-un VM propriu, separat de mașina ta și de celelalte sesiuni.
• Control de rețea — accesul la rețea e limitat implicit și poate fi dezactivat complet, prin nivelurile de acces ale mediului. Atenție la nuanța pe care documentația o spune explicit: chiar și cu rețeaua dezactivată, sesiunea comunică în continuare cu API-ul Anthropic, deci datele pot ieși din VM pe acel canal.
• Protecția credențialelor git — credențialele și cheile de semnare stau în afara sandbox-ului, iar un proxy se autentifică în numele sesiunii cu credențiale cu domeniu limitat.
• Analiză în interiorul mediului — codul e analizat și modificat în sesiunea izolată, înainte de crearea unui pull request.

Mediile în sine sunt configurabile: acces la rețea, variabile de mediu, script de pregătire. Un mediu implicit, cu acces de rețea „de încredere", se creează la prima utilizare.

Capcanele pe care le descoperi abia în producție

Expirarea mediului. Sesiunile din cloud se opresc după o perioadă de inactivitate, iar VM-ul e recuperat. Redeschizi sesiunea și primești o mașină nouă, cu istoricul conversației restaurat — dar munca din fundal care rula în acel moment nu se restaurează: subagenți, comenzi de shell, procese pornite. O sesiune care așteaptă aprobarea ta pentru un conector se consideră inactivă și poate expira chiar în timpul acelei așteptări.

Lista de IP-uri permise. Dacă organizația are IP allowlisting activ, fiecare sesiune găzduită de Anthropic eșuează cu eroare de autentificare, pentru că apelurile pleacă din infrastructura Anthropic, nu din rețeaua voastră. Aceeași problemă atinge și rutinele programate. Se rezolvă doar prin exceptare, cerută suportului Anthropic. E genul de detaliu care oprește un pilot în prima zi, dacă nu l-ai anticipat.

Limitele de utilizare sunt comune. Sesiunile web împart limitele cu restul utilizării contului, iar rularea mai multor sarcini în paralel le consumă proporțional. Nu există o taxă separată pentru VM.

Zero Data Retention exclude funcția. Organizațiile cu Zero Data Retention activ nu pot folosi /web-setup și nici celelalte funcții de sesiuni în cloud.

Nu tot ce merge în terminal merge și acolo. /clear nu există în sesiunile din cloud — pornești o sesiune nouă din bara laterală. /compact și /context funcționează. Comenzi ca /model sau /effort se folosesc cu argument (/model sonnet), nu prin selectorul din terminal.

Partajarea are implicit diferit, pe planuri. Pe Enterprise și Team, opțiunile sunt „privat" și „echipă", cu verificarea accesului la repository activată implicit. Pe Max și Pro, a doua opțiune este „public" — vizibil oricărui utilizator autentificat pe claude.ai — iar verificarea accesului la repository nu e activată implicit. O sesiune poate conține cod și credențiale din repo-uri private. Verific-o înainte să dai linkul.

Auto-fix poate declanșa automatizări. Claude poate urmări un pull request și răspunde automat la eșecuri de CI și la comentarii de review, iar răspunsurile pe GitHub sunt postate din contul tău, etichetate ca venind de la Claude Code. Documentația avertizează direct: dacă repository-ul folosește automatizări declanșate de comentarii — Atlantis, Terraform Cloud, acțiuni proprii pe issue_comment — un comentariu poate porni infrastructură. Nu activa auto-fix pe repo-urile unde un comentariu deployează. Despre ce merită automatizat în review și CI, și ce nu, am scris separat în articolul despre code review cu agenți.

Când muți execuția pe infrastructura ta

Pentru echipele care nu pot trimite execuția în afara rețelei există mediile găzduite propriu, în beta publică pe planurile Team și Enterprise, dezactivate implicit; un Owner le activează din setările de administrare, iar funcția cere ca Claude Code pe web să fie deja activ în organizație.

Arhitectura are trei piese: mediul (o destinație cu nume, creată în setările de administrare), runner-ul (un proces pe care îl rulezi pe mașinile tale, ideea fiind aceeași ca la un runner de CI self-hosted) și sesiunea. Când un dezvoltator alege mediul vostru, planul de control Anthropic pune sesiunea într-o coadă, un runner o preia, clonează repo-ul și pornește un proces Claude Code pe mașina voastră. Tot traficul e ieșit din rețeaua voastră, HTTPS către api.anthropic.com; formularea documentației e fără echivoc: Anthropic nu inițiază niciodată conexiuni către rețeaua voastră.

Ce rămâne la voi: checkout-urile de cod, artefactele de build, secretele și fișierele create de sesiune. Ce pleacă în continuare: conversația în sine — prompturi, răspunsuri și rezultate de unelte — merge la api.anthropic.com pentru inferență, iar transcrierea sesiunii e stocată de Anthropic, ca să poți relua sesiunea de pe alt dispozitiv. Self-hosting-ul mută execuția, nu inferența.

Restricțiile de care trebuie să știi înainte să-l propui: nu e disponibil pentru organizațiile cu Zero Data Retention, inferența nu poate fi rutată prin Bedrock, platforma Google Cloud, Microsoft Foundry sau un gateway propriu, iar repo-urile se clonează din GitHub. Facturarea e aceeași ca la mediile Anthropic.

Și o realitate operațională, spusă chiar de documentație: majoritatea echipelor sunt mai bine servite de mediile administrate de Anthropic, fiindcă nu cer nimic de întreținut. Self-hosting-ul înseamnă că tu construiești imaginea runner-ului, operezi flota și îi controlezi rețeaua — adică o componentă de platformă în plus, cu rotație de imagini, capacitate, monitorizare și degradare controlată. Dacă echipa ta nu are deja practicile astea, e exact genul de muncă tratat în cursul AI pentru DevOps și SRE (AIOps), și e mai bine învățată înainte, nu în timpul primului incident.

Câștigul, în schimb, e concret: sesiunile ajung la servicii interne, baze de date și registre fără să le expui pe internet, imaginea runner-ului vine cu compilatoarele și uneltele voastre preinstalate, iar checkout-urile rămân pe infrastructura voastră.

Decizia, pe tipuri de cod

• Cod public sau proiecte proprii, fără date sensibile: sesiuni în cloud, fără ezitare. Aici câștigi cel mai mult din paralelizare.
• Cod de client sub NDA: verifică întâi contractul, apoi decide. Dacă nu ai voie să trimiți sursele în afara rețelei, rămâi local cu Remote Control sau treci pe mediu găzduit propriu.
• Sisteme reglementate, rețea închisă: mediu găzduit propriu, cu politica de organizație pentru sesiuni în cloud configurată explicit — nu lăsată pe implicit.
• Repo-uri unde un comentariu poate deploya: auto-fix oprit, indiferent de restul deciziilor.

Politica de organizație (allow_remote_sessions) și celelalte comutatoare de administrare nu sunt formalități: când sunt oprite, comenzile explică asta utilizatorului, în loc să eșueze obscur. Stabilește-le înainte ca oamenii să-și facă obiceiuri. Pentru contextul mai larg al guvernanței agenților în companii, vezi și articolul despre agenți AI în enterprise.

Întrebări frecvente

Care e diferența dintre --cloud și Remote Control?

--cloud creează o sesiune care rulează pe altă mașină — o VM administrată de Anthropic sau un runner din rețeaua ta — pornind de la o clonă a repo-ului. Remote Control lasă sesiunea pe calculatorul tău și îți dă doar o fereastră către ea, din browser sau de pe telefon. Prima mută execuția, a doua mută doar controlul.

Sesiunea din cloud vede modificările mele nesalvate?

Nu, dacă repo-ul are remote GitHub: VM-ul clonează remote-ul pe branch-ul curent, deci trebuie să faci push înainte. Când repo-ul nu are remote sau aplicația GitHub nu e instalată, Claude Code împachetează repo-ul local și îl urcă, incluzând modificările necomise la fișierele urmărite, dar nu și fișierele neurmărite.

Pot să iau o sesiune din cloud și să continui în terminal?

Da, cu claude --teleport sau /teleport dintr-o sesiune pornită. Ai nevoie de working directory curat, de un checkout al aceluiași repository, de branch-ul împins pe remote și de același cont. După teleportare, sesiunea din terminal e o copie separată: ce faci local nu se mai reflectă în cea din cloud.

Rămâne codul companiei în afara infrastructurii noastre?

Depinde de unde rulează sesiunea. Într-un mediu găzduit propriu, checkout-urile, artefactele și secretele rămân pe mașinile voastre, dar conversația — prompturi, răspunsuri, rezultate de unelte — ajunge la API-ul Anthropic pentru inferență, iar transcrierea sesiunii e stocată acolo. Nu există variantă de sesiune în cloud fără acest schimb.

De ce eșuează toate sesiunile din cloud în firma noastră?

Cel mai probabil din cauza listei de IP-uri permise: sesiunile găzduite de Anthropic apelează API-ul din infrastructura Anthropic, nu din rețeaua voastră, deci allowlist-ul le respinge. Se rezolvă cerând suportului Anthropic o exceptare. A doua cauză frecventă e politica de organizație pentru sesiuni în cloud, oprită de un administrator.

Concluzie

Sesiunile în cloud nu sunt „Claude Code, dar în browser". Sunt o schimbare de loc al execuției, cu tot ce decurge de aici: un repo clonat de pe GitHub în loc de checkout-ul tău, un model de rețea și de credențiale diferit, limite de utilizare comune, o listă de IP-uri care poate bloca totul din prima zi și o politică de partajare care, pe planurile individuale, are „public" la un click distanță. Odată înțelese, câștigul e real — sarcini autonome în paralel, pornite din terminal și continuate de pe telefon, cu --cloud la plecare și /teleport la întoarcere. Iar pentru echipele care nu pot trimite execuția afară, mediile găzduite propriu rezolvă exact partea de execuție, fără să pretindă că rezolvă și inferența.

Articol informativ, redactat la 12 septembrie 2026 pe baza documentației oficiale citate, consultate la această dată. Funcțiile aflate în research preview sau beta se schimbă frecvent — verifică documentația înainte de a construi un proces în jurul lor. Conținutul nu constituie consultanță juridică sau de conformitate.

Surse

• Anthropic — „Use Claude Code on the web": sesiuni în cloud, --cloud, --teleport, partajare, auto-fix, izolare și limitări
• Anthropic — „Remote Control": continuarea unei sesiuni locale de pe alt dispozitiv
• Anthropic — „Self-hosted environments": rularea sesiunilor în cloud pe infrastructura ta
• Anthropic — „Run agents in parallel": subagenți, agent view, echipe de agenți și workflow-uri dinamice
• Anthropic — „Cloud environments": acces la rețea, variabile de mediu și scripturi de pregătire