Codex Cloud Environments, bulutta kod görevi açarken her seferinde aynı araçları kurma sorununa yanıt veriyor. Geliştirme düzeninizi tarif ediyor, Codex'in depoyu ve bağımlılıkları hazırlayıp test etmesini sağlıyor, ardından bu ortamı yayımlıyorsunuz. Yeni görevler hazırlanmış dosya sisteminden, birbirinden izole çalışma alanlarında başlıyor.
DevDay duyurusundaki ikinci vurgu, görevin web, mobil veya masaüstünden izlenebilmesi ve kişisel bilgisayar uyusa da bulutta çalışmaya devam etmesi. Bu, her repo ve her servis için sınırsız yetki demek değil. Ağ, gizli bilgiler, özel servislere erişim ve ortam paylaşımı ayrı ayarlar. Yayımlanmadan önce gerçek proje testinin geçtiğini görmek gerekir.
Bu yazının duyuru ve erişim bilgileri OpenAI’nın resmî özellik belgesi ile DevDay 2026 toplu duyurusu üzerinden doğrulandı. Örnek proje ve deneme önerileri editoryal yorumdur.
Ortam kurmanın yeni akışı
Resmî kılavuzda web veya masaüstünde Work in > Cloud seçilip yeni ortam oluşturuluyor. Codex depo içindeki runtime, paket sürümü, araç ve servisleri tanımaya çalışıyor. Kullanıcı konuşma içinde kurulum sorununu düzeltebiliyor; ayrı bir kurulum betiği yazmak zorunlu değil. Hazırlık test edildiğinde ortam yayımlanıyor. Böylece yeni bir görev yalnız boş makineyle başlamıyor. Yine de otomatik algılama bir doğrulama garantisi değil; yerel projede çalışan testin bulutta da çalıştığı incelenmeli.
Yayımlanmış durum ve görev durumu
Yeni görev, yayımlanmış ortamın hazırlanmış dosya sisteminden başlıyor. Var olan görev ise kendi kaydedilmiş dosyaları, commitlenmemiş değişiklikleri ve kurulu araçlarıyla sürüyor. Bu iki kural özellikle güncellemede önemli. Ortama yeni paket eklemek mevcut bir görevin diskini geriye dönük değiştirmiyor. Bir ekipte “ortam v2 yayımlandı” ile “eski görev v1'den başladı” ayrımını kaydetmek hata ayıklamayı kolaylaştırır. Yeni görevleri açmadan önce hangi ortam sürümünün seçildiği kontrol edilmeli.
İzole çalışma alanı neden değerli?
Aynı ortamdan başlamak, görevlerin aynı dosyayı birlikte değiştirdiği anlamına gelmiyor. Her yeni görev kendi VM ve çalışma alanında ilerliyor. Bu, iki farklı özellik dalı veya iki hata düzeltmesi üzerinde çalışırken birbirinin kurulumunu bozmamayı sağlar. Entegrasyon sonunda değişikliklerin nasıl birleştirileceği hâlâ Git ve insan incelemesiyle yönetilir. Ortam tekrar kullanımı, kod birleştirme stratejisinin yerine geçmez; sadece başlangıç koşulunu daha öngörülebilir yapar.
Sır ve ağ erişimini tasarlamak
Kılavuz environment variables ve network secrets için ayrı yönetim yolu açıklıyor. Kişisel değerler kullanıcının kasasından verilebilir; ekip ortamında gerekli sırların kim tarafından sağlanacağı planlanmalı. İnternet erişimi ve izinli alan adları, paket yöneticileri ve özel servis bağlantıları da ayrı ele alınır. Bir marka sitesinin CMS önizleme API'si gerekiyorsa yalnız “internet açık” demek yeterli olmayabilir. Hangi API'ye hangi kimlikle erişileceğini baştan sınırlandırmak, kurulumun tekrar edilebilirliği kadar önemlidir.
Web, mobil ve masaüstü devamı
Ortam web veya masaüstünde hazırlanıp yayımlandıktan sonra bulut görevleri web ve mobilde de açılabilir. Kılavuz, mobilde Codex içinden uygun ortam seçmeyi anlatıyor. Bilgisayarınızın uyuması bulut VM'ini durdurmuyor; bu, uzun süren test ve kod işleri için pratik. Ancak mobilin, ortamın ilk kurulum ve gizli bilgi yönetiminde bütün masaüstü kontrollerini sunduğu sonucu çıkmıyor. İlk kurulumu rahat inceleyebileceğiniz bir ekranda yapmak daha güvenli.
Örnek: çok servisli web projesi
Bir Next.js ön yüzü, içerik API'si ve görsel dönüştürme işçisi olan projeyi düşünelim. Ortam hazırlanırken paket sürümleri, test komutları ve geliştirme servisleri tek tek doğrulanır. Ön izleme için örnek içerik ve gerçek müşteri verisi ayrılır. Yayımlanan ortamdan “mobil menü hatasını düzelt” ve “görsel performansını ölç” görevleri ayrı açılır. Bu editoryal senaryoda hedef, her görevin aynı kurulumu yeniden bulmaması; teslimden önce iki değişikliğin ayrı testlerden ve ortak kod incelemesinden geçmesi.
Ekip içinde paylaşma
Uygun Enterprise çalışma alanında hazırlanmış ortam iş arkadaşlarıyla paylaşılabiliyor. Bu paylaşım, herkesin kişisel sırlarına otomatik erişim vermez; kılavuz kullanıcıya özgü değerlerin ayrı sağlanabileceğini anlatıyor. Paylaşım yapmadan önce depo erişimi, ağ politikası, gerekli test verisi ve ortamı kim güncelleyecek soruları cevaplanmalı. “Bir kişide çalışıyor” durumunu ekip standardına çevirmek için yalnız ortamı yayımlamak yetmez; ilk yeni görevi başka bir ekip üyesiyle de denemek gerekir.
Sınırlamalar ve karar ölçütü
Bulut ortamı her geliştirici makinesinin bire bir kopyası değildir. Yerel cihaz sürücüsü, özel VPN, lisanslı yazılım veya erişim kısıtlı servis gerekiyorsa kılavuzdaki destek ve sınırlar kontrol edilmeli. Ağ ayarı ile Agent Security politikası da birlikte değerlendirilir; bir yerde izinli alan adı diğer yerde otomatik izin oluşturmaz. Benim başarı ölçümüm yeni görevin çalışır hale gelme süresi, kurulum hatası sayısı, test tekrarlanabilirliği ve teslim sonrası sürpriz sayısı olurdu.
Hazırlık tamam sayılmadan önce
Codex ortam kurduğunu söylediğinde en az bir gerçek test ve bir uygulama başlatma adımı görmek isterim. Sadece paketlerin kurulması yeterli değil; gerekli veritabanı göçü, build komutu, font/görsel işleme aracı veya özel servis mock'u da çalışmalı. Projenin kısa kurulum belgesindeki önemli bağımlılıkları ortam açıklamasına eklerdim. Birden fazla repo varsa hangilerinin aynı ortama dahil edildiği netleşmeli. Yayımlanan hazır dosya sistemi sonraki görevlere temel olacak; kurulum hatasını burada yakalamak, on göreve yayılmadan düzeltmek demek. Bu nedenle ilk ortamı üretim değil doğrulama artefaktı gibi ele almak doğru.
Sürüm değişikliğinde bakım rutini
Paket sürümü veya depo yapısı değişince yayımlanmış ortamın güncellenmesi gerekebilir. Ben ortam sahibini ve yenileme tetiklerini belirlerdim: yeni Node sürümü, yeni test servisi, erişim değişikliği, önemli bağımlılık. Güncellemeden sonra sıfırdan yeni görev açıp kurulumun hazır başladığını görmek gerekir; var olan görevin hâlâ çalışması yeni ortamı kanıtlamaz. Ayrıca önceki görevlerin kendi dosya durumuyla devam edeceği ekipte anlatılmalı. Böylece “ortam güncellendi ama bu görev eski davranıyor” sorunu sürpriz olmaz. Ortam değişim kaydı, kod deposundaki sürüm notu kadar yararlı olabilir.
Ağ ve özel servisleri tasarlamak
Bir bulut görevi npm paketini indirebiliyor ama şirket içi API'ye gidemiyorsa ortam çalışır görünürken gerçek iş eksik kalır. Resmî kılavuz internet alan adları, VPN ve OIDC gibi farklı bağlantı yollarını açıklıyor. Her dış bağımlılığı haritada işaretlerdim: paket yöneticisi, CMS, görsel CDN, test API'si, kimlik sağlayıcı. Ardından hangisi kurulumda, hangisi görev sırasında gerekli ayrılır. Gerekmeyen sırları ortama eklemek yerine göreve veya kişisel kasaya uygun değer verilir. Özel ağ ihtiyacı varsa yalnız internet anahtarını açmak yeterli olmayabilir; VPN ve politika birlikte test edilmeli.
Mobil devamın doğru beklentisi
Bulutta açılmış görevin telefon üzerinden izlenebilmesi, mobilde aynı geliştirme ergonomisinin bulunduğu anlamına gelmiyor. Ben mobilden kısa karar, test sonucunu okuma ve öncelik değiştirme gibi işleri beklerim; uzun diff incelemesini büyük ekrana bırakırım. Ortamın web veya masaüstünde önce yayımlanmış olması gerekiyor. Müşteri toplantısındayken bulut görevinin ilerlediğini görmek güçlü; ama telefondan onaylanan bir değişikliğin hangi dosyalara dokunduğunu sonra masaüstünde gözden geçirmek gerekir. Bu çalışma biçimi, bilgisayar kapalıyken görev yürütme avantajını inceleme kalitesini düşürmeden kullanır.
Ortam değerini sayıyla görmek
Bir ay boyunca yeni görevlerin ilk başarılı testine kadar geçen süreyi ölçerdim. Ortam öncesi her görevde paket kurulumuna 15 dakika gidiyor, ortam sonrası bir dakikada teste başlanıyorsa kazanım açık. Ama sürekli yeniden kurulum hataları, ağ izin sorunları veya güncel olmayan paketler çıkıyorsa hazırlık maliyeti büyür. Paylaşılan Enterprise ortamında ikinci bir geliştiricinin ilk denemesi kritik; yalnız ortamı yaratan kişide çalışması ekip tekrar kullanılabilirliği kanıtlamaz. En az bir üretim benzeri görev ve bir farklı kullanıcı testi sonrası geniş paylaşım kararı verirdim.
Kurulum yönergesinin okunabilirliği
Codex'in ortamı konuşma içinde hazırlaması, kurulum bilgisinin yalnız sohbet geçmişinde kalması gerektiği anlamına gelmez. Ortamın hangi repo sürümünden, hangi paket ve servislerle hazırlandığını kısa bir README veya ekip notunda tutardım. Yeni çalışan, otomatik hazırlık bozulduğunda elle neyi kontrol edeceğini bilmeli. Sırların değeri yazılmaz; yalnız hangi tür gizli değerin gerektiği belgelenir. Ortamın sahibi ve yenileme günü de not edilir. Bu yazılı kayıt, tekrar kullanılabilir dosya sistemiyle birlikte ortamı sürdürülebilir hale getirir.
Üretim verisi yerine test verisi
Bulut ortamına gerçek müşteri API anahtarını veya canlı veritabanını bağlamak kolay test yolu gibi görünebilir; ama ilk kurulumda gerekmez. Önce örnek veya maskelenmiş veriyle build ve testleri doğrularım. Gerçek dış servis gerekiyorsa en az yetkili kimlik, sınırlandırılmış domain ve kayıtlı erişim kullanılır. Resmî kılavuz network secrets, OIDC ve VPN gibi araçlar sunsa da bunlar otomatik güvenlik kararı vermez. Hazır ortamın her yeni göreve temel olması, yanlış bir sırrın çok sayıda göreve taşınması riskini artırabilir. Yayım öncesi gizli bilgi incelemesi bu yüzden zorunlu.
Sonuç
Cloud Environments, Codex bulut görevini yeniden üretilebilir başlangıç noktasına yaklaştırıyor. Kurulumu anlatıp test ettikten sonra yayımlamak ve her işi izole alanda başlatmak değerli. Fakat sır, ağ ve sürüm yönetimi ürünün dışında bırakılmamalı. Küçük bir depo üzerinde ilk kurulum, ikinci kullanıcı testi ve yeni görev doğrulaması başarılıysa daha karmaşık projeye geçmek mantıklı.
Sık sorulan sorular
Bilgisayarım kapalıyken Codex Cloud çalışır mı?
Evet. Yayımlanmış Cloud Environment içindeki bulut görevleri kişisel bilgisayar uyurken devam edebilir.
Ortamı güncellersem eski görev değişir mi?
Kılavuza göre mevcut görev kendi kaydedilmiş dosyalarıyla sürer; yeni görev yayımlanmış hazır ortamdan başlar.
Gizli bilgiler ortamla herkese geçer mi?
Hayır varsaymamak gerekir. Ortak ve kişisel değerler için ayrı yönetim seçenekleri ve erişim kontrolleri var.
İlgili yazılar
- DevDay 2026: bütün duyurular
- Codex'te Astra Ultrafast: Hız, Erişim ve Kullanım Bedeli
- Codex Security Cloud: GitHub Taraması ve Kanıtlı Bulgular