Yönetilen yapılandırma

Yönetilen yapılandırma, kurumsal yöneticilerin ChatGPT Work ve Codex için desteklenen gereksinimleri ve varsayılan değerleri belirlemesini sağlar. Gereksinimler, kullanıcıların ve görevlerin yapabileceklerini sınırlar. Varsayılan değerler başlangıç değerlerini sağlar. Destek; ürüne, istemci sürümüne ve yürütme ortamına bağlıdır.

Desteklenen buluttan yönetilen ayarlar için Admin Console içindeki Agent Security bölümünden başlayın. Yaygın görevler için ayar denetimlerini kullanın veya yapılandırma metnini incelemek, kopyalamak ya da düzenlemek için Edit as TOML seçeneğini belirleyin. Her iki görünüm de aynı politikayı düzenler; TOML, özel bir denetimi bulunmayan desteklenen alanları da sunar. Buluttan yönetilen ayarları kullanmak için yerel bir dosya dağıtmanız gerekmez. Kimlik doğrulama kısıtlamaları ve cihaz üzerinden yönetilen dağıtımlar için ayrı bir yerel kurulum vardır.

Kurumsal yöneticiler, desteklenen yerel istemci davranışlarını şu yollarla denetleyebilir:

• Gereksinimler: yöneticilerin zorunlu kıldığı ve kullanıcıların geçersiz kılamadığı kısıtlamalar.

• Yapılandırma varsayılanları: sistem veya bulut üzerinden yönetilen ve kullanıcıların geçersiz kılabildiği config.toml ayarları.

• Eski yönetilen varsayılanlar: desteklenen bir istemci başlatıldığında uygulanan managed_config.toml başlangıç değerleri. Kullanıcılar bir çalıştırma sırasında ayarları değiştirmeye devam edebilir. İstemci, bir sonraki başlatılışında bu varsayılan değerleri yeniden uygular.

Global temel ayarları, ortama özgü geçersiz kılmalar ve orkestratör ile yürütücü alan listeleri için Agent Security sayfasına bakın.

Agent Security içinde bir politika yapılandırın

Agent Security etkin olduğunda çalışma alanı sahipleri, çalışma alanı yöneticileri ve Codex yönetici izinlerine sahip üyeler politikaları yönetebilir. Politika düzenleyicisine erişim, üyelere politikanın denetlediği özelliklere erişim sağlamaz.

Çalışma alanının temel ayarları için Workspace default seçeneğini kullanın. Belirli kullanıcılar, gruplar veya roller farklı ayarlara ihtiyaç duyduğunda Overrides seçeneğini kullanın. Hedef kitleye yönelik bir geçersiz kılma, politikanın kimlere uygulanacağını belirler; ortam ayarı ise desteklenen yürütme denetimlerinin nerede uygulanacağını belirler.

1. Admin Console > Agent Security bölümünü açın ve Workspace default seçeneğini veya Overrides altında düzenlemek istediğiniz politikayı seçin.
2. Zorunlu sınırları belirlemek için Requirements bölümünü, üyelerin bu sınırlar içinde değiştirebileceği başlangıç değerlerini belirlemek için Defaults bölümünü açın.
3. Onay, web araması ve ajanın tamamına uygulanan diğer ayarları Global içinde tutun. Kullanılabildiği durumlarda, desteklenen yürütme ayarları için Local Environments veya Codex Cloud Environments eklemek üzere ilgili karttaki Add environment settings seçeneğini kullanın. Boş bir ortam belgesi ayarları Global'den devralır; mevcut temel ayarları kopyalamaz veya sabitlemez.
4. Bu kılavuzda açıklanan denetimleri kullanın. Gelişmiş alanlar için Edit as TOML seçeneğini belirleyin ve ilgili kapsamın requirements.toml veya config.toml dosyasını düzenleyin. Görsel düzenleyiciye dönmek için Use settings controls seçeneğini belirleyin.
5. Doğrulama iletilerini inceleyin, ardından Save changes seçeneğini belirleyin. Bir kuralı kural düzenleyicisinde uygulamak taslağı günceller; tek başına politikayı kaydetmez.
6. Politika seçimini ve desteklenen istemci davranışını Yönetici ve çalışan deneyimini doğrulayın bölümünde açıklandığı şekilde kontrol edin.

Ortam düzenleyicileri ve desteklenen alanlar, çalışma alanına ve politikaya bağlıdır. Global içindeki bir ayarı bir ortama taşımadan önce Ayarların uygulandığı yerler bölümüne bakın. Global içindeki bir ayar, her ürüne veya yürütme yoluna mutlaka uygulanmaz.

Bir yapılandırmayı kopyalayın veya yeniden kullanın

Görsel düzenleyici TOML'nin yerini almaz. Bir yapılandırmayı kopyalamak, başvuru kopyasını saklamak veya ayarları başka bir politikada yeniden kullanmak için Edit as TOML seçeneğini belirleyin. Görsel düzenleyiciye dönmek için Use settings controls seçeneğini belirleyin.

1. Kaynak politikayı açın ve Edit as TOML seçeneğini belirleyin.
2. Kopyalamak istediğiniz kapsamı seçin: Global veya kullanılabilir bir ortam sekmesi. Yeniden kullanmak istediğiniz ayarlara göre Requirements (requirements.toml), Defaults (config.toml) veya her ikisindeki metni kopyalayın.
3. Hedef politikayı açın, Edit as TOML seçeneğini belirleyin ve eşleşen kapsamı seçin. Gereksinimleri requirements.toml dosyasına, varsayılanları ise config.toml dosyasına yapıştırın. Metni değiştirmeden önce hedefteki mevcut ayarları inceleyin; uygulanmaya devam etmesi gereken ilgisiz ayarları koruyun.
4. Doğrulama iletilerini, hedef politikanın hedeflerini ve önceliğini inceleyin, ardından Save changes seçeneğini belirleyin. Kopyalanan politikaya güvenmeden önce ortaya çıkan istemci davranışını doğrulayın.

Kopyalanan metin, söz konusu politika ve kapsam için tanımlanan ayarları içerir. Atamaları, politika sırasını, diğer ortam belgelerini veya başka politikalarla cihaz ayarlarının birleştirilmesiyle oluşan etkin yapılandırmayı içermez. Gerektiğinde ortam ayarlarını ayrı olarak kopyalayın. Görünümler arasında geçiş yapmak veya metin kopyalamak, politika değişikliğini kaydetmez.

Aşağıdaki örneği deneyin: bir ayarı değiştirin, ardından yapılandırmasını görmek için Edit as TOML seçeneğini belirleyin. Denemeye devam etmek için Use settings controls ile geri dönün.

allowed_approval_policies = ["on-request"]
allowed_sandbox_modes = ["read-only"]
allowed_web_search_modes = ["disabled"]

Doğru denetimi seçin

Tarayıcıyı ve Computer Use özelliğini denetleyin

Desteklenen masaüstü istemcilerinde tarayıcı ve yerel uygulama erişimini yönetmek için Admin Console içindeki Agent Security bölümünü kullanın. Arayüz denetimleriyle başlayın. Aşağıdaki TOML örnekleri, dosya tabanlı politika dağıtımı ve TOML düzenleyicisi gerektiren ayarlar için bir yapılandırma başvuru kaynağı sunar.

Browser Use, bir tarayıcıda ajan tarafından yürütülen etkinlikleri denetler. Computer Use ise yerel masaüstü uygulamalarında ajan tarafından yürütülen etkinlikleri denetler. Yerleşik tarayıcı bölmesinin ayarları Browser Use ayarlarından ayrıdır. Tarayıcı erişim yolları arasındaki farklar için tarayıcı oturumları ve mevcut oturum açma bilgileri bölümüne bakın.

Başlamadan önce

Agent Security politikalarını yönetme iznine sahip bir hesap kullanın. Politikanın kimlere uygulanacağını ve hangi istemci sürümlerini ve işletim sistemlerini desteklemeniz gerektiğini doğrulayın. Politika atamaları, Global ayarları ve desteklenen ortam geçersiz kılmaları için Agent Security bölümünü inceleyin.

Kullanıcıların geçersiz kılamayacağı sınırlar için Requirements bölümünü kullanın. Defaults, bu sınırlar içindeki başlangıç değerlerini belirler. Bir siteye veya uygulamaya izin vermek eklenti yüklemez, işletim sistemi izinlerini vermez, kullanıcı adına oturum açmaz veya hâlâ inceleme gerektiren bir işlemi onaylamaz.

Masaüstü özelliklerinin kullanılabilirliği altında Tarayıcı kullanımı, Harici tarayıcı kullanımı ve Bilgisayar kullanımı ayarlarını inceleyin. Zorunlu olarak kapat, ilgili özelliği devre dışı bırakır; bir site veya uygulamaya yönelik izin kuralı bunu geçersiz kılmaz. Tam CDP erişimi ayarını ayrıca inceleyin; Kullanıcının etkinleştirmesini engelle, kullanıcıların bu ayarı etkinleştirmesini önler.

Bu masaüstü denetimleri, barındırılan Work Cloud tarayıcısını yapılandırmaz. Bulut tarayıcısı kullanımı ve Bulut ağ erişimi ayarlarını Yönetici Konsolu > İzinler ve roller > Çalışma alanı özellikleri > Bulut bilgisayarı özellikleri altında ayrı ayrı yönetin. Agent Security'nin Work Cloud'a nasıl uygulandığına bakın.

Tarayıcı erişimini yapılandırın

1. Yönetici Konsolu > Ajan güvenliği bölümünü açın. Çalışma alanının temel ayarları için Çalışma alanı varsayılanı seçeneğini kullanın veya Geçersiz kılmalar altındaki ilgili ilkeyi açın. Gereksinimler bölümünde Masaüstü tarayıcı denetimleri seçeneğine gidin.
2. Site kuralları bölümünde Varsayılan satırının eylemlerini açın ve Varsayılanı düzenle seçeneğini belirleyin. Erişimi onaylanmış sitelerle sınırlamak için Site erişimi ayarını Engelle olarak ayarlayın, ardından Kuralı uygula seçeneğini belirleyin. Varsayılan satırı, eşleşen bir site kuralında Varsayılan kuralı kullan olarak bırakılan ayarların değerlerini sağlar.
3. Site kuralı ekle seçeneğini belirleyin. Site veya desen alanına bir kaynak girin: şema, ana bilgisayar adı ve isteğe bağlı bağlantı noktası. Örneğin, https://example.com geçerlidir; https://example.com/files geçerli değildir. Yol, sorgu veya parça eklemeyin. HTTP ve HTTPS farklı kaynaklardır. Bağlantı noktası, şemanın varsayılanından farklıysa bağlantı noktasını belirtin.
4. Site erişimi ayarını yapın ve İndirmeler, Yüklemeler ve Hata ayıklama/CDP ayarlarını inceleyin. Uygun şekilde İzin ver veya Engelle seçeneğini belirleyin ya da ayarı Varsayılan kuralı kullan olarak bırakın. Hata ayıklama/CDP, tarayıcıda hata ayıklamak için tam Chrome DevTools Protocol erişimini denetler. İzin ver, normal ilke ve onay denetimlerinin devam etmesini sağlar.
5. Site için Otomatik inceleme, Her zaman izin ver ve Onay süresi ayarlarını inceleyin. Onay süresi, Bu tur ve Bu konuşma dizisi seçeneklerini sunar. Masaüstü tarayıcı denetimleri bölümündeki Tarayıcı geçmişi, Site onaylarını kaydet ve İstekleri otomatik onayla ayarlarını da inceleyin.
6. Kural ekle seçeneğini belirleyin, doğrulama mesajlarını inceleyin ve Değişiklikleri kaydet seçeneğini belirleyin. İlkeyi alan desteklenen bir istemcide izin verilen bir siteyi ve engellenen bir siteyi test edin. Yüklemeleri, indirmeleri ve diğer kısıtlanmış eylemleri ayrı ayrı test edin.

Site kuralı ekle

Bir site kuralında bir izin Varsayılan olarak bırakıldığında Varsayılan satırı uygulanır. Kurallar çakışırsa her izin için Engelle geçerli olur.

Site veya desen 

Site erişimiVarsayılan kuralı kullan

İndirmelerVarsayılan kuralı kullan

YüklemelerVarsayılan kuralı kullan

Hata ayıklama/CDPVarsayılan kuralı kullan

Otomatik incelemeVarsayılan kuralı kullan

Her zaman izin verVarsayılan kuralı kullan

Onay süresiVarsayılan kuralı kullan

Tarayıcı eylemleri için otomatik incelemenin devre dışı bırakılması, bu eylemlerin onay için kullanıcıya gönderilmesini sağlar. Model güvenliği izlemesini devre dışı bırakmaz.

Birden fazla kaynak deseni eşleştiğinde, her ayar için en kısıtlayıcı değer geçerli olur. Yerel yapılandırma, yönetilen bir engellemeyi gevşetemez. Yönetilen ağ engellemeleri ve yalnızca listelenenlere izin veren listeler tarayıcı araçları için de geçerlidir. Kaynak desenleri ve onay davranışı için tarayıcı ilkesi alanlarına bakın.

Bilgisayar Kullanımı, bir tarayıcıyı yerel uygulama olarak da çalıştırabilir. Tarayıcı Kullanımı site ve yetenek kuralları bu yönteme uygulanmaz. Yerel uygulama erişimini ayrıca inceleyin; tarayıcı güvenliği sınırlarına bakın.

Yerel uygulama erişimini yapılandırın

1. Gereksinimler bölümünde Masaüstü uygulama denetimleri > Uygulama kuralları seçeneğine gidin.
2. Eşleşen bir kuralı olmayan uygulamalar için erişimi yapılandırmak üzere Varsayılan satırının eylemlerini kullanın. Bilgisayar Kullanımını onaylanmış uygulamalarla sınırlamak için erişimi varsayılan olarak engelleyin ve bu uygulamalar için izin kuralları ekleyin.
3. Uygulama kuralı ekle seçeneğini belirleyin. Kuralı düzenle iletişim kutusunda Uygulama alanından macOS bundle ID, Windows AUMID veya Windows yürütülebilir dosyası seçeneğini belirleyin. Paket kimliği veya Application User Model ID (AUMID) için tam Uygulama tanımlayıcısını girin. Windows yürütülebilir dosyası için Yayımcı adı ve Ürün adı bilgilerini girin; İkili dosya adı isteğe bağlıdır. Görünen ad veya dosya yolu yerine doğrulanmış uygulama kimliği bilgilerini kullanın.
4. Kuralın Uygulama erişimi ayarını yapın, ardından Kural ekle seçeneğini belirleyin. Masaüstü uygulama denetimleri altındaki Uygulama onaylarını kaydet ayarını ve doğrulama mesajlarını inceleyin, ardından Değişiklikleri kaydet seçeneğini belirleyin. Kaydedilmiş onayları devre dışı bırakmak, geçerli oturum için onay verilmesine yine de izin verir; onayların kaydedilmesine izin vermek bir uygulamayı onaylamaz.
5. Dağıtımınızda desteklenen her işletim sisteminde izin verilen bir uygulamayı ve engellenen bir uygulamayı test edin. İşletim sistemi izinlerinin hâlâ geçerli olduğunu ve kullanıcıların gerekli onayları vermeye devam etmesi gerektiğini doğrulayın.

Kuralı düzenle

Varsayılan uygulama erişimini ayarlayın ve eşleşen uygulamalar için geçersiz kılın.

UygulamamacOS bundle ID

Uygulama tanımlayıcısı 

Uygulama erişimiErişim seçin

Windows kimlik gereksinimleri için Bilgisayar Kullanımı ilkesi alanlarına, yönetilen Mac'ler içinse kilitliyken kullanım kısıtlamalarına bakın.

Etkin ilkeyi kontrol edin

İzin verilen bir site veya uygulama hâlâ engelleniyorsa eşleşen diğer kuralları, ilke atamalarını ve önceliğini, cihaz gereksinimlerini ve kullanıcı yapılandırmasını kontrol edin. Bir kaynaktaki izin kuralı, geçerli olan başka bir engellemeyi aşmaz. Gereksinimlerin konumlarına ve öncelik sırasına bakın.

Bir ayarın etkisi yoksa istemcinin, işletim sisteminin ve ilke iletim yolunun bu ayarı desteklediğini doğrulayın. Yerel bilgisayar erişimi olan Work Cloud'a özellikle dikkat edin: bazı alanlar kısmen desteklenir veya doğrulama gerektirir. Yapılandırma Başvurusu'ndaki Work uyumluluğuna bakın.

Bir kullanıcı özelliğe veya gerekli eklentiye erişemiyorsa çalışma alanı izinlerini ve eklenti denetimlerini ayrı ayrı kontrol edin.

TOML yapılandırma başvurusu

Aşağıdaki örnekler, requirements.toml için aynı ilke amacını açıklar. İlkeyi dosyalar veya TOML düzenleyicisi aracılığıyla yönetirken bu örnekleri kullanın. Agent Security'deki kontrolleri kullanmak için yerel bir dosyayı düzenlemeniz gerekmez.

Bu tarayıcı örneği erişimi varsayılan olarak reddeder, https://example.com adresine izin verir, bu sitede yüklemeleri ve tam CDP erişimini engeller ve site erişim onayını geçerli turla sınırlar:

[browser_use]
allow_history_access = false
allow_global_persistent_approval = false

[browser_use.default_origin_policy]
access = "deny"

[browser_use.origins."https://example.com"]
access = "allow"
uploads = "deny"
downloads = "allow"
full_cdp_access = "deny"
persistent_approval = false
access_approval_lifetime = "turn"

Tarayıcı eylemleri için otomatik incelemeyi devre dışı bırakmak üzere browser_use.disable_auto_review = true ayarını yapın veya belirli bir kaynak için bunu kısıtlamak üzere kaynak ilkesinde auto_review = "deny" ayarını yapın.

Uygun bir Enterprise çalışma alanında Site araçlarını etkinleştirmek için browser_use.allow_webmcp = true ayarını yapın. Yönetilen bu etkinleştirme seçeneği, masaüstü uygulamasının yerleşik tarayıcısı için geçerlidir. Değeri false olarak ayarlamak veya ayarı belirtmemek, normal özellik kullanılabilirliği denetimlerini korur; false bir engelleme uygulamaz. Kullanıcı tercihleri ve site izinleri geçerliliğini korur.

Bu yerel uygulama örneği macOS'te Calculator'a izin verir, diğer uygulamaları varsayılan olarak reddeder ve uygulama onaylarının oturumlar arasında kalıcı olmasını önler:

[computer_use]
default_app_access = "deny"
allow_persistent_approval = false

[computer_use.macos.bundle_ids]
"com.apple.calculator" = "allow"

Windows ilkeleri, paketlenmiş uygulamaları computer_use.windows.aumids veya çalıştırılabilir dosyaları computer_use.windows.exes ile tanımlayabilir. Çalıştırılabilir dosya kuralları için publisher_name, product_name ve access gereklidir; binary_name isteğe bağlıdır.

Desteklenen tüm alanlar ve değerler için requirements.toml başvurusunu kullanın. Tek tek siteleri veya uygulamaları kısıtlamak yerine bir yeteneği devre dışı bırakmak için Özellik bayraklarını sabitleme bölümüne bakın.

Diğer masaüstü kontrolleri

Aşağıdaki masaüstü kontrolleri özellik kullanılabilirliğini, Locked Use'u, Appshots'ı ve cihazın uzaktan kontrolünü kapsar. Özellik kullanılabilirliği ve Locked Use için özel ayarları kullanın; Appshots'ı ve cihazın uzaktan kontrolünü Edit as TOML ile yapılandırın. Masaüstü uygulaması trafiğindeki hedef kısıtlamaları için Masaüstü uygulamasının ağ hedeflerini kontrol etme bölümüne bakın.

Özellik bayraklarını sabitleme

Agent Security'de sunulan masaüstü özellikleri için Global > Requirements > Desktop feature availability yolunu açın. In-app browser, Browser use, External browser use veya Computer use ayarını Force off olarak ayarlayarak ilgili yeteneği devre dışı bırakın, ardından Save changes seçeneğini seçin. Full CDP access için, kullanıcıların bunu etkinleştirmesini önlemek üzere Block user opt-in seçeneğini seçin. Bir özelliğe izin vermek, ürün, platform veya kullanıma sunulma durumundan kaynaklanan kullanılabilirlik koşullarını geçersiz kılmaz.

Desteklenen diğer özellik bayrakları için, Edit as TOML seçeneğini ve Global requirements.toml belgesini veya desteklenen bir yerel gereksinim kaynağını kullanın. Aşağıdaki örnekler hem çalışma zamanına hem de masaüstüne özgü özellik sabitlemelerini içerir:

[features]
hooks = true
unified_exec = false

# Disable surface-specific features when needed.
browser_use = false
browser_use_full_cdp_access = false
browser_use_external = false
in_app_browser = false
in_app_updates = false
computer_use = false

Çalışma zamanı özellikleri için config.toml dosyasının [features] tablosundaki standart özellik anahtarlarını kullanın. Yerel çalışma zamanı, tanınan özellikleri bu sabitlemelere uyacak şekilde normalleştirir ve config.toml dosyasındaki veya profil dosyasındaki özellik ayarlarına yapılan çakışan yazma işlemlerini reddeder.

Yönetilen bir unified_exec = false ayarı, komut çalıştırmayı kullanılabilir tutar ancak devam ettirilebilir süreçleri ve write_stdin aracını devre dışı bırakır. Kullanıcı yapılandırması bu özelliği devre dışı bırakamaz.

• in_app_browser = false yerleşik tarayıcı bölmesini devre dışı bırakır.
• in_app_updates = false desteklenen ortamlarda ChatGPT masaüstü uygulamasının kendi güncelleyicisini yeniden başlatıldığında devre dışı bırakır. Harici paket dağıtımını etkilemez veya eski uygulama sürümlerinin destek süresini uzatmaz. Kurulum ve kullanıma sunma rehberliği için Uygulama güncellemelerini yönetme bölümüne bakın.
• browser_use = false desteklenen Browser Use yeteneklerini devre dışı bırakır. Harici Browser Use ve yerel uygulamalardaki Computer Use için ayrı kontroller bulunur.
• browser_use_full_cdp_access = false yerel çalışma zamanında Browser Developer modu dahil tam CDP erişimini devre dışı bırakır ve ChatGPT masaüstü uygulamasının ilgili ayarı etkinleştirmesini önler.
• browser_use_external = false desteklenen tarayıcı uzantıları üzerinden ajan tarafından yürütülen Browser Use'u devre dışı bırakır.
• computer_use = false bir tarayıcının yerel uygulama olarak çalıştırılması dahil, yerel uygulamalardaki Computer Use'u, Record & Replay'i ve ilgili yükleme veya kurulum akışlarını devre dışı bırakır.

Yalnızca Browser Use'u devre dışı bırakmak, tüm tarayıcı erişim yollarını engellemez. Yerel uygulamalardaki Computer Use, bu yeteneğe ve uygulama erişimine izin verildiğinde tarayıcıyı kullanmaya devam edebilir; Browser Use site ve yetenek kuralları bu yol için geçerli değildir. Bunu engellemek için Computer use ayarını Force off (computer_use = false) olarak ayarlayın veya diğer yerel uygulamaların kullanılabilir kalması gerekiyorsa App rules içinde tarayıcı uygulamasını reddedin. External browser use ve In-app browser ayarlarını ayrı ayrı inceleyin. Her yol için geçerli kontrolleri öğrenmek üzere tarayıcı oturumları ve mevcut oturum açma bilgileri bölümüne bakın.

Bu anahtarları belirtmezseniz ilke, normal istemci, platform ve kullanıma sunulma koşullarına bağlı olarak özelliklere izin verir.

Kilitliyken bilgisayar kullanımını kısıtlama

Kullanıcıların yönetilen bir Mac'te Locked Use özelliğini etkinleştirmesini önlemek için Global > Requirements > Desktop app controls yolunu açın, Allow use while locked ayarını Disabled olarak ayarlayın ve Save changes seçeneğini seçin. Bu ayar, Locked Use'un zaten etkin olduğu bir Mac'te özelliği kapatmaz.

TOML düzenleyicisi veya cihaz yönetimi aracılığıyla dağıtım için eşdeğer gereksinim şöyledir:

[computer_use]
allow_locked_computer_use = false

Bu gereksinim, Locked Use'u etkinleştirmeye yönelik kontrolleri kaldırır. Zaten etkinse Locked Use'u kapatmaz. Bunu belirtmezseniz normal ürün kullanılabilirliği ve kullanıcının yerel ayarı geçerliliğini korur.

Appshots'ı devre dışı bırakma

Appshots, desteklenen istemcilerin uygulama anlık görüntülerini dahil etmesini sağlar. Buluttan yönetilen kullanıcılar için bunları devre dışı bırakmak üzere Agent Security'de Edit as TOML seçeneğini açın ve Global requirements.toml belgesindeki en üst düzey allow_appshots alanını ayarlayın. Cihazdan yönetilen dağıtımlar için geçerli yerel gereksinim kaynağını kullanın:

allow_appshots = false

Appshots'ın kullanılabildiği ortamlarda allow_appshots = false bunları devre dışı bırakır. Anahtarı belirtmezseniz gereksinimler Appshots'ı kısıtlamaz ve normal ürün kullanılabilirliği denetimleri uygulanır. Geçerli gereksinimleri configRequirements/read aracılığıyla okuyan uygulama sunucusu istemcileri aynı kısıtlamayı allowAppshots olarak alır; belirtilmemiş veya null olan bir allowAppshots değeri Appshots'ı devre dışı bırakmaz.

Cihazın uzaktan kontrolünü devre dışı bırakma

Buluttan yönetilen kullanıcılar için cihazın uzaktan kontrolünü devre dışı bırakmak üzere Agent Security'de Edit as TOML seçeneğini kullanın ve Global requirements.toml belgesindeki en üst düzey allow_remote_control alanını ayarlayın. Ayrıca desteklenen bir yerel gereksinim kaynağında allow_remote_control ayarını yapabilirsiniz:

allow_remote_control = false

Cihazın uzaktan kontrolünün desteklendiği ortamlarda allow_remote_control = false bunu devre dışı bırakır. Anahtarı belirtmezseniz gereksinimler cihazın uzaktan kontrolünü kısıtlamaz ve normal ürün kullanılabilirliği denetimleri uygulanır. Bu gereksinim, SSH uzak bağlantılarını devre dışı bırakmaz.

Onayları ve çalıştırma izinlerini ayarlama

Onay davranışını, izin sınırlarını ve başlangıç varsayılanlarını ayarlamak için bu bölümü kullanın. İlke sınırları ve Varsayılanlar ile başlayın. Sonraki görevler; inceleyici zorunluluğu, özel izin profilleri, dosya sistemi kısıtlamaları, ana makine geçersiz kılmaları ve komut kuralları için TOML gereksinimlerini açıklar.

Yönetici tarafından zorunlu tutulan gereksinimler (requirements.toml)

Gereksinimler, güvenlik açısından hassas ayarları (onay politikası, onayları inceleyen taraf, otomatik inceleme politikası, korumalı alan modu, izin profilleri, web arama modu, yönetilen kancalar, kullanıcıların hangi MCP server öğelerini etkinleştirebileceği ve hangi eklenti pazar yeri kaynaklarını kullanabileceği) kısıtlar. Yapılandırma çözümlenirken (örneğin config.toml, profil dosyaları veya CLI yapılandırma geçersiz kılmalarından), bir değer zorunlu kılınan bir kuralla çelişirse yerel istemci uyumlu bir değere döner ve kullanıcıyı bilgilendirir. Bir mcp_servers izin listesi yapılandırırsanız istemci, bir MCP server öğesini yalnızca hem adı hem de kimliği onaylanmış bir kayıtla eşleştiğinde etkinleştirir; aksi takdirde devre dışı bırakır.

Gereksinimler, requirements.toml içindeki [features] tablosu aracılığıyla özellik bayraklarını da kısıtlayabilir. Özelliklerin her zaman güvenlik açısından hassas olmadığını, ancak kuruluşların isterse değerleri sabitleyebileceğini unutmayın. Atlanan anahtarlar kısıtlanmadan kalır.

Codex 0.138.0 veya sonraki sürümlerde allowed_permission_profiles ve yönetilen default_permissions ile izin profillerini tercih edin. allowed_sandbox_modes öğesini yalnızca hâlâ sandbox_mode yapılandıran eski dağıtımlar için kullanın.

Tam anahtar listesi için Yapılandırma Referansı'ndaki requirements.toml bölümüne bakın.

Onay, korumalı alan ve web araması sınırlarını ayarlama

Desteklenen istemci seçeneklerini sınırlamak için Requirements > Policy guardrails yolunu kullanın. Bu kontroller yapılandırmayı kısıtlar; başlangıç değerini seçmez. Başlangıç değerini Defaults altında ayrıca ayarlayın.

1. Global bölümünde Approval policies öğesini açın ve izin verilen onay biçimlerini seçin. Örneğin Ask when needed, ajanın korumalı alan yetkilerini yükseltme gibi eylemler için onay istemesine izin verir. Never ask, onay isteklerini engeller; sınırsız yürütme yetkisi vermez.
2. Eski korumalı alan seçeneklerini sınırlamak için Sandbox modes öğesini açın. Read-only, yazma işlemlerini kısıtlar; Workspace write, çalışma alanında ve yapılandırılmış yazılabilir köklerde yazmaya izin verir; Full access ise dosya sistemi korumalı alanını kaldırır. sandbox_mode yerine izin profilleri kullanan dağıtımlar için izin profili gereksinimlerini kullanın.
3. Global bölümünde, web aramasını sınırlamak için Web search modes öğesini açın. Canlı arama olmadan önbelleğe alınmış aramaya izin vermek için Cached, web aramasını kapatmak için Disabled seçeneğini belirleyin. Web araması kısıtlamaları, komut ağı kurallarından ayrıdır.
4. İzin verilen seçenekleri ve bunlara karşılık gelen varsayılanları gözden geçirin, ardından Save changes öğesini seçin.

Bir gereksinimi ayarlamamak, ilgili politika kapsamında herhangi bir sınır getirmez. Geçerli diğer politikalar uygulanmaya devam eder. Ask for untrusted commands seçeneği, gereksinimlerin izin listesinde untrusted değerine karşılık gelir; kullanımdan kaldırılan approval_policy = "untrusted" ayarının açıkça kullanılmasını yeniden desteklemez. Bu durum için aşağıdaki geçiş rehberini izleyin.

Web aramasını kısıtlamak için Global > Requirements > Policy guardrails > Web search modes yolunu kullanın. Eşdeğer TOML şöyledir:

allowed_web_search_modes = ["cached"] # "disabled" remains implicitly allowed

allowed_web_search_modes = [] yalnızca "disabled" değerine izin verir. Örneğin allowed_web_search_modes = ["cached"], danger-full-access oturumlarında bile canlı web aramasını engeller.

Yapılandırma varsayılanlarını ayarlayın

Varsayılanlar, üyelere bir başlangıç yapılandırması sağlar. Herhangi bir kısıtlamayı zorunlu kılmaz veya bir çalışma alanı özelliğine erişim vermez.

1. Politikanın Defaults kartını açın. Ajanın tamamı için geçerli varsayılanları Global bölümünde tutun; desteklenen yürütme varsayılanları için kullanılabilir bir ortam sekmesini kullanın.
2. Command execution altında başlangıç Approval policy ve Approval reviewer değerlerini ve uygun Sandbox mode veya Default permissions seçeneğini belirleyin. İnceleyici, onay isteklerini varsayılan olarak kimin inceleyeceğini; onay politikası ise isteklerin ne zaman yapılabileceğini belirler.
3. Web search altında başlangıç Web search modunu ve Web search context değerini seçin. Apps and tools altında, desteklenen uygulama araçları için Apps/connectors, Open-world tools ve Destructive tools öğelerini gözden geçirin.
4. Varsayılanların Requirements gereksinimlerinizi karşıladığını doğrulayın, ardından Save changes öğesini seçin.

Eklenti pazaryeri yapılandırması gibi görsel denetimi bulunmayan desteklenen varsayılanlar için Edit as TOML öğesini kullanın. Bu bulut varsayılanları, normal yapılandırma önceliğini kullanır. Başlangıçta yönetilen varsayılanları yerel yapılandırmanın üzerinde konumlandıran eski managed_config.toml önceliğinden farklıdır.

Örnek requirements.toml

Bu örnek, --ask-for-approval never ve --sandbox danger-full-access öğelerini (--yolo dâhil) engeller:

allowed_approval_policies = ["untrusted", "on-request"]
allowed_sandbox_modes = ["read-only", "workspace-write"]

Burada untrusted, daha katı onay davranışını korur; bu davranışın kaynağı trust_level = "untrusted" ayarıdır. Bu, approval_policy = "untrusted" ayarının açıkça belirtilmesini desteklenen bir seçenek hâline getirmez.

Kullanımdan kaldırılan untrusted onay politikasından geçiş yapın

Codex ve ChatGPT Work artık approval_policy = "untrusted" ayarını desteklemiyor. Bu ayarı yönetilen varsayılanlardan, eski managed_config.toml dosyasından ve onu ayarlayan tüm kullanıcı, proje, profil veya başlangıç yapılandırmalarından kaldırın.

Etkileşimli, salt okunur kullanım için approval_policy = "on-request" ayarını, yönetilen gereksinimlerinizin izin verdiği salt okunur bir korumalı alan veya izin profiliyle birlikte seçin. Bu korumalı alanın izin verdiği komutlar onay olmadan çalışabilir.

Daha katı komut onaylarını korumak için açık bir approval_policy ayarı belirtmeyin; trust_level = "untrusted" ayarını kullanıcı düzeyindeki ~/.codex/config.toml dosyasında projenin girdisine ekleyin ve untrusted değerini allowed_approval_policies içinde tutun. Bu işlem, proje yerelindeki yapılandırmayı da devre dışı bırakır. on-request değerinin açıkça ayarlanması bu politikayı geçersiz kılar. Örnekler ve güvenlik açısından ödünleşimler için Kullanımdan kaldırılan untrusted onay politikasından geçiş yapın bölümüne bakın.

Otomatik inceleme politikasını yapılandırın

Otomatik incelemeyi varsayılan yapmak için Global > Defaults > Command execution > Approval reviewer yolunu kullanın. Varsayılan bir değer, kullanıcıların izin verilen başka bir inceleyiciyi seçmesine olanak tanır. Otomatik incelemeyi zorunlu kılmak veya kuruluşunuzun inceleme talimatlarını sağlamak için Edit as TOML öğesini kullanarak Global kapsamındaki requirements.toml dosyasını düzenleyin. Bu gereksinimler, tarayıcının otomatik inceleme denetimlerinden ayrıdır.

Otomatik incelemeyi zorunlu kılmak veya buna izin vermek için allowed_approvals_reviewers kullanın. Otomatik incelemeyi zorunlu kılmak için bu ayarı ["auto_review"] olarak ayarlayın; kullanıcılar manuel onayı seçebiliyorsa "user" değerini de ekleyin.

Otomatik inceleme politikasının kiracıya özgü bölümünü değiştirmek için guardian_policy_config ayarını yapın. Yerel çalışma zamanı, yerleşik inceleyici şablonunu ve çıktı sözleşmesini kullanmaya devam eder. Yönetilen guardian_policy_config, yerel [auto_review].policy ayarından önceliklidir.

allowed_approval_policies = ["on-request"]
allowed_approvals_reviewers = ["auto_review"]

guardian_policy_config = """
## Environment Profile
- Trusted internal destinations include github.com/my-org, artifacts.example.com,
  and internal CI systems.

## Tenant Risk Taxonomy and Allow/Deny Rules
- Treat uploads to unapproved third-party file-sharing services as high risk.
- Deny actions that expose credentials or private source code to untrusted
  destinations.
"""

Kullanılabilir izin profillerini denetleme

Kullanıcıların başlangıçta kullanacağı yerleşik profili seçmek için Defaults > Command execution > Default permissions yolunu kullanın. Kullanıcıların hangi profilleri seçebileceğini zorunlu kılmak veya özel profiller tanımlamak için Edit as TOML öğesini kullanın ve requirements.toml ayarını uygun Global kapsamında veya desteklenen yürütme ortamı kapsamında yapılandırın. Yalnızca bir varsayılan seçmek, kullanılabilir profilleri kısıtlamaz.

Kullanıcıların hangi yerleşik ve özel izin profillerini seçebileceğini denetlemek için allowed_permission_profiles kullanın. Bu, allowed_sandbox_modes öğesinin izin profili karşılığıdır; kullanıcılarınızın izin seçme biçimiyle eşleşen izin listesini kullanın.

İzin profili izin listeleri Codex 0.138.0 veya sonraki bir sürümü gerektirir. Codex 0.137.0 ve önceki sürümler allowed_permission_profiles ile yönetilen default_permissions öğesini yok sayar.

Aşağıdaki izin profili örneklerini yalnızca yönetilen her istemci desteklenen bir sürümü çalıştırdıktan sonra kullanın. İstemci grubu yükseltmesi tamamlanmadan yönetilen özel profilleri dağıtmayın.

Tablo mevcut olduğunda izin verilen profillerin eksiksiz listesidir. true olarak ayarlanan profillere izin verir; gelecekteki Codex sürümlerinde eklenecek yerleşik profiller dâhil olmak üzere atlanan veya false olarak ayarlanan profilleri reddeder.

Standart profillere izin verme

Bu politika salt okunur erişime ve çalışma alanı erişimine izin verir, ancak tam erişime izin vermez:

default_permissions = ":workspace"

[allowed_permission_profiles]
":read-only" = true
":workspace" = true
# ":danger-full-access" is omitted, so it is denied.

Yönetilen, en düşük ayrıcalıklı bir varsayılan ekleme

Yöneticiler aynı gereksinim kaynağında özel bir profil tanımlayabilir. Kullanıcıların yüklenen yapılandırmalarındaki adlarla çakışmayacak, kuruluşa özgü profil adları kullanın. Özel adlar : ile başlayamaz veya ayrılmış filesystem adını kullanamaz.

Yönetilen özel profilleri Codex 0.137.0 veya önceki sürümleri çalıştıran istemcilere dağıtmayın. Bu istemciler profil tablosunu tanır, ancak onu seçen yönetilen varsayılanı tanımaz.

Örneğin:

default_permissions = "acme_review_only"

[allowed_permission_profiles]
":read-only" = true
":workspace" = true
acme_review_only = true
# ":danger-full-access" is intentionally omitted, so it is denied.

[permissions.acme_review_only]
description = "Review code without modifying the workspace."
extends = ":read-only"

Yalnızca kuruluş tarafından tanımlanan profillere izin verme

Kullanıcıların yalnızca yönetici tarafından tanımlanan profilleri seçmesi gerekiyorsa tüm yerleşik profilleri atlayın:

default_permissions = "acme_workspace"

[allowed_permission_profiles]
acme_workspace = true

[permissions.acme_workspace]
description = "Workspace access with sensitive files denied."
extends = ":workspace"

[permissions.acme_workspace.filesystem]
glob_scan_max_depth = 3

[permissions.acme_workspace.filesystem.":workspace_roots"]
"**/*.env" = "deny"

Kullanıcılar yerleşik :workspace profilini doğrudan seçemese bile özel profil :workspace öğesini genişletebilir.

Başka bir kaynağın izin verdiği profili kapatma

İzin listeleri profil adına göre birleştirilir. Bulut gereksinimleri sistem gereksinimlerinden daha yüksek önceliğe sahip olduğundan, sistem dosyasının izin verdiği bir profili kapatmak için bulut gereksinimleri false kullanabilir.

Bulut gereksinimleri:

default_permissions = ":read-only"

[allowed_permission_profiles]
":read-only" = true
":workspace" = false

Sistem gereksinimleri:

[allowed_permission_profiles]
":read-only" = true
":workspace" = true  # Not honored because cloud requirements set this to false.

default_permissions değerini açıkça izin verilen bir profile ayarlayın. Atlanırsa yerel çalışma zamanı yalnızca hem :workspace hem de :read-only açıkça izinli olduğunda varsayılan olarak :workspace kullanır. allowed_permission_profiles yoksa yönetilen gereksinimler kullanıcıların seçebileceği profil adlarını kısıtlamaz. Her kayıt, yerleşik bir profili veya yüklenen bir yapılandırma ya da gereksinim kaynağında tanımlanmış özel bir profili adlandırmalıdır. Davranışlarını merkezi olarak denetlemek için özel profilleri yönetilen gereksinimlerde tanımlayın.

Okumayı engelleme gereksinimlerini uygulayın

Uygun Global kapsamındaki veya desteklenen yürütme ortamındaki requirements.toml dosyasına dosya sistemi kısıtlamaları eklemek için Edit as TOML öğesini kullanın. Bu kısıtlamalar, hassas yolların okunmasını engeller; salt okunur bir varsayılan tek başına dosyaları gizlemez.

Yöneticiler, [permissions.filesystem] ile tam olarak belirtilen yollar veya glob kalıpları için okumayı engelleyebilir. Kullanıcılar, yerel yapılandırmayla bu gereksinimleri gevşetemez.

[permissions.filesystem]
deny_read = [
  # values can be absolute paths...
  "/**/*.env",
  # ...or relative to $HOME/%USERPROFILE% using `~`.
  "~/.ssh",
  # But relative paths starting with `./` are not allowed.
]

Okumayı engelleme gereksinimleri bulunduğunda yerel çalışma zamanı, tam erişim izinlerini reddeder ve bu gereksinimleri uygulayabilmek için yerel yürütmeyi salt okunur veya çalışma alanı korumalı alanında tutar. Yerel Windows ortamında yönetilen deny_read, doğrudan dosya araçlarına uygulanır; kabuk alt süreçlerinin okuma işlemleri bu korumalı alan kuralını kullanmaz.

Korumalı alan gereksinimlerini ana makineye göre geçersiz kılma

Ana makineye özgü gereksinimler oluşturmak için Agent Security bölümündeki Edit as TOML öğesini kullanın. Ortam denetimleri bir yürütme ortamı seçer; ana makine kalıpları ise desteklenen çalışma zamanı içindeki eşleşen makineleri seçer.

Tek bir yönetilen politikanın farklı ana makinelerde farklı korumalı alan gereksinimleri uygulaması gerektiğinde [[remote_sandbox_config]] kullanın. Örneğin, eşleşen geliştirme makinelerinde veya CI çalıştırıcılarında çalışma alanına yazmaya izin verirken dizüstü bilgisayarlar için daha katı bir varsayılanı koruyabilirsiniz. Ana makineye özgü kayıtlar şu anda yalnızca allowed_sandbox_modes öğesini geçersiz kılar:

allowed_sandbox_modes = ["read-only"]

[[remote_sandbox_config]]
hostname_patterns = ["*.devbox.example.com", "runner-??.ci.example.com"]
allowed_sandbox_modes = ["read-only", "workspace-write"]

Yerel çalışma zamanı, her hostname_patterns kaydını mümkün olan en iyi şekilde çözümlenmiş ana makine adıyla karşılaştırır. Kullanılabildiğinde tam nitelikli alan adını tercih eder, aksi takdirde yerel ana makine adını kullanır. Eşleştirme büyük/küçük harfe duyarsızdır; * herhangi bir karakter dizisiyle, ? ise tek bir karakterle eşleşir.

Aynı gereksinim kaynağında eşleşen ilk [[remote_sandbox_config]] kaydı geçerli olur. Hiçbir kayıt eşleşmezse yerel çalışma zamanı üst düzey allowed_sandbox_modes değerini korur. Ana makine adı eşleştirmesi yalnızca politika seçimi içindir; bunu kimliği doğrulanmış cihaz kanıtı olarak değerlendirmeyin.

Gereksinimler üzerinden komut kurallarını uygulayın

Global kapsamındaki requirements.toml dosyasına komut kuralları ve MCP server kısıtlamaları eklemek için Agent Security bölümündeki Edit as TOML öğesini kullanın. Komut kuralları, eşleşen komutlar için onay veya ret kararlarını belirtir; MCP kısıtlamaları, istemcinin hangi sunucu kimliklerini etkinleştirebileceğini sınırlar. Approval policies denetimi, bu kural kümelerinden hiçbirini oluşturmaz.

Yöneticiler ayrıca requirements.toml üzerinden kısıtlayıcı komut kurallarını bir [rules] tablosu kullanarak uygulayabilir. Bu kurallar normal .rules dosyalarıyla birleştirilir ve en kısıtlayıcı karar geçerli olmaya devam eder.

.rules dosyalarından farklı olarak gereksinim kuralları, decision belirtmelidir ve bu karar "prompt" veya "forbidden" olmalıdır ("allow" olamaz).

[rules]
prefix_rules = [
  { pattern = [{ token = "rm" }], decision = "forbidden", justification = "Use git clean -fd instead." },
  { pattern = [{ token = "git" }, { any_of = ["push", "commit"] }], decision = "prompt", justification = "Require review before mutating history." },
]

Yerel bir istemcinin hangi MCP server'ları etkinleştirebileceğini kısıtlamak için bir mcp_servers onay listesi ekleyin. stdio sunucuları için command üzerinden; akış destekli HTTP sunucuları için url üzerinden eşleştirin:

[mcp_servers.docs]
identity = { command = "codex-mcp" }

[mcp_servers.remote]
identity = { url = "https://example.com/mcp" }

identity.command değerinin dize biçimi yalnızca yapılandırılmış command ile eşleşir. args, cwd, env veya env_vars değerlerini incelemez.

Bir stdio çağrısının tamamını kısıtlamak için yürütülebilir dosyayı ve her bir konumsal bağımsız değişkeni eşleştirin:

[mcp_servers.internal.identity]
command = { executable = "/usr/local/bin/codex-mcp", args = [
  { match = "exact", value = "serve" },
  { match = "prefix", value = "--workspace=" },
] }

Yürütülebilir dosya, bağımsız değişken sayısı ve bağımsız değişken sırası eşleşmelidir. Bağımsız değişken ve URL kuralları, exact, prefix ve değerin tamamını kapsayan regex eşleştirmesini destekler. Yapılandırılmış komut kuralları da cwd, env veya env_vars değerlerini incelemez. Eklentilerle birlikte gelen MCP server'lar, aynı kimlik yapılarını plugins.<plugin>.mcp_servers.<server> altında kullanır.

mcp_servers mevcut ancak boşsa yerel istemci tüm MCP server'ları devre dışı bırakır.

Ağ erişimini yapılandırın

Komutların ağ erişimi ve masaüstü uygulamalarının ağ erişimi farklı denetimler kullanır. Desteklenen komut trafiği için Network use controls ile başlayın, ortam ve çalışma zamanı sınırlarını gözden geçirin, ardından gerekirse ayrı masaüstü uygulaması gereksinimlerini kullanın. Tarayıcı site kuralları Tarayıcıyı ve Computer Use özelliğini denetleyin bölümünde yer almaya devam eder.

Ağ erişimi gereksinimlerini yapılandırma

Agent Security bölümünde desteklenen komutların ağ erişimini yönetmek için Requirements > Network use controls yolunu kullanın. Ortak bir temel yapılandırmayı Global bölümünde; ortama özgü yürütme ayarlarını ise kullanılabilir bir Local Environments veya Codex Cloud Environments sekmesinde yapılandırın.

1. Alan adı kurallarını yönetilen komut trafiğine uygulamak için Managed networking ayarını On olarak belirleyin. Yalnızca alan adı kuralları eklemek, yönetilen proxy'yi etkinleştirmez.
2. Network rules altında Add network rule seçeneğini seçin. Domain alanına api.openai.com veya **.example.com gibi, URL şeması ya da yol içermeyen bir alan adı girin. Access altında Allow veya Deny seçeneğini belirleyin, ardından taslağı güncellemek için Save rule seçeneğini seçin. Diğer hedefler için işlemi tekrarlayın.
3. Kullanıcı ayarlarının ve alan adı bazındaki onayların yönetilen izin listesini genişletmemesi gerekiyorsa Only allow domains added by admins ayarını On olarak belirleyin. Gerekli Allow girdilerini ekleyin; yalnızca ret kuralları içeren bir liste diğer hedeflere izin vermez.
4. Yerel dinleyiciler veya özel ağ hedefleri gerektiren iş akışları için Allow local network access ayarını gözden geçirin. Doğrudan yerel bağlantılar, proxy'nin alan adı kurallarını atlayabilir. Bu ayarı değiştirmeden önce aşağıdaki Codex Cloud bağlantı sınırlarını gözden geçirin.
5. Devralınan kuralları ve doğrulama iletilerini gözden geçirin, ardından Save changes seçeneğini seçin. Etkilenen her yürütme ortamında başarılı olması gereken bir isteği ve engellenmesi gereken bir isteği test edin.

Managed networking ayarını Off olarak belirlemek, o kapsamda tanımlanmış ağ kurallarını temizler ve açık bir kapalı değeri kaydeder; internet erişimini devre dışı bırakmaz. Not set, geçerli ilkenin veya çalışma zamanı varsayılanlarının uygulanabilmesi için bu kapsamda tanımlanmış ağ ayarlarını kaldırır. Ortam ayarlarının kaldırılması, devralınan Global kurallarını ortaya çıkarabilir. Gelişmiş ağ alanları veya görsel düzenleyicinin gösteremediği mevcut eski alan adı listeleri için Edit as TOML seçeneğini kullanın.

Yöneticilerin ağ erişimi gereksinimlerini merkezi olarak tanımlaması gerektiğinde requirements.toml içinde [experimental_network] kullanın. Bu gereksinimler, kullanıcıya ait features.network_proxy geçiş düğmesinden ayrıdır: bu özellik bayrağı olmadan korumalı alan ağını yapılandırabilirler ancak etkin korumalı alan ağı kapalı tuttuğunda komutlara ağ erişimi vermezler. Yönetilen proxy'yi etkinleştirmek için experimental_network.enabled = true değerini ayarlayın; yalnızca alan adı kuralları proxy'yi etkinleştirmez.

[experimental_network]
enabled = true
managed_allowed_domains_only = true

[experimental_network.domains]
"api.openai.com" = "allow"
"**.example.com" = "allow"
"blocked.example.com" = "deny"
"**.exfil.example.com" = "deny"

experimental_network.managed_allowed_domains_only = true seçeneğini yalnızca [experimental_network.domains] içinde yöneticiye ait "allow" girdileri de tanımladığınızda ve erişimin yalnızca bu kurallardaki izinlerle sınırlanmasını istediğinizde kullanın. Yönetilen izin kuralları yokken bu değer true ise kullanıcıların eklediği alan adı izin kuralları geçerliliğini korumaz. Standart domains eşlemesini eski allowed_domains veya denied_domains listeleriyle birlikte kullanmayın.

*.example.com yalnızca alt alan adlarıyla eşleşir. **.example.com kök alan adıyla ve onun alt alan adlarıyla eşleşir. Eşleşen bir engelleme kuralı, izin kuralına üstün gelir.

Alan adı söz dizimi, yerel/özel hedef kuralları, reddetmenin izin vermeye üstün gelmesi davranışı ve DNS yeniden bağlama sınırlamaları, Ajan onayları ve güvenlik bölümünde açıklanan korumalı alan ağı davranışıyla aynıdır.

Proxy, korumalı alan içinde çalışan yerel komutları yönlendirir. Tarayıcı araçları ayrıca bir kaynağa erişmeden önce yönetilen ağ engellemelerini ve erişimi yalnızca listelenen hedeflerle sınırlayan izin listelerini kontrol eder. Bu, tarayıcı trafiğini komut proxy'si üzerinden yönlendirmekten ayrı bir ilke kontrolüdür. Web aramasını, uygulamaları ve bağlayıcıları, MCP server öğelerini, yerel uygulama trafiğini, Codex hizmet isteklerini veya diğer yeteneklere özgü trafiği filtrelemez. Her arayüz için ilgili denetimleri kullanın:

• Web aramasını kısıtlamak için allowed_web_search_modes kullanın.
• Uygulama ve bağlayıcı entegrasyonlarını devre dışı bırakmak için features.apps = false, desteklenen yerlerde eklentileri devre dışı bırakmak için features.plugins = false kullanın.
• MCP server öğelerini kısıtlamak için yönetilen mcp_servers onaylı listesini kullanın.
• Tarayıcı ve bilgisayar kullanımı yeteneklerini kısıtlamak için browser_use, in_app_browser ve computer_use gibi özellik gereksinimlerini kullanın.
• Desteklenen yönetilen Codex Cloud komutları için Agent Security gereksinimlerini ve Cloud ortamının internet ayarlarını ayrı ayrı yapılandırın.

Komut alan adları için izin verilenler listesi, bu yeteneğe özgü denetimlerin yerini almaz.

Desteklenen yönetilen Codex Cloud yürütme yollarında, Agent Security gereksinimleri komutların ağ erişimini kısıtlar. Codex Cloud ortamının internet ayarları ayrıca uygulanır. Agent Security içinde izin verilen bir alan adı, Cloud ortamının internet ayarlarındaki bir kısıtlamayı geçersiz kılmaz. Komutların ağ erişimine yönelik bu denetimler, tek başlarına barındırılan web aramasını, uygulamaları veya MCP'yi devre dışı bırakmaz. ChatGPT Work Cloud, ayrı yetenek izinlerine sahiptir ve bu Agent Security gereksinimlerini devralmaz.

Yönetilen komut izin listesi, yönetilen proxy'yi kullanan komutlara uygulanır. İlkenin korumalı alan kısıtlamalarının tamamen kaldırılmasına izin verdiği ve bunun onaylandığı durumlarda, söz konusu yürütme komut proxy'sini atlayabilir. Dar kapsamlı bir ağ izni, korumalı alan kısıtlamalarının tamamen kaldırılmasından farklıdır. Zorunlu onay ve korumalı alan gereksinimlerini amaçlanan sınıra göre yapılandırın; hem normal komutları hem de yükseltilmiş yetkilerle çalışan komutları test edin.

Geçerli izin verilen hedef yok: Managed networking ve Only allow domains added by admins ayarları On olduğunda, normal yönetilen komutlar için geçerli izin verilen hedefler gerekir. Hiçbir Allow girdisi yapılandırılmamış veya devralınmamışsa bu komutların izin verilen hedefi yoktur. Yalnızca ret kuralları içeren bir ilke, internetin geri kalanına örtülü olarak izin vermez. Kaydetmeden önce gerekli Allow girdilerini ekleyin ve devralınan kuralları kontrol edin. Bu kısıtlama, tüm araçlara veya onaylanmış tam korumalı alan yetki yükseltmelerine değil, yönetilen komut proxy'sine uygulanır.

Codex Cloud yerel/özel ağ bağlantısı: Yerel/özel ağ bağlantısı için açıkça belirlenmiş bir Kapalı değeri, hedef etki alanına izin verilse bile Codex Cloud'un üst akış proxy'sine ulaşmasını engelleyebilir. Nihai allow_local_binding değerini kontrol edin ve bu değeri hangi politikanın veya ayarın sağladığını belirleyin. Desteklenen Cloud proxy yolunda bu değer, yalnızca geçerli bir gereksinim, seçili ağ profili veya proxy özelliği ayarı tarafından bir değer sağlanmadığında varsayılan olarak true olur. Devralınan bir false değeri de açıkça belirlenmiş bir ayar sayılır. Desteklendiği durumlarda, Local tarafından kullanılan Global değerini değiştirmeden Codex Cloud için bu değeri değiştirmek üzere daha yüksek öncelikli bir Cloud geçersiz kılma ayarı tanımlayın. Bu işlem, etki alanı Allow girdileri eklemez. Geçersiz kılma ayarına güvenmeden önce yürütücü desteğini doğrulayın. Bu Cloud varsayılanını Local için uygulamayın.

Ortam gereksinimleri boş olduğunda Global gereksinimleri uygulanır. Managed networking ayarının Off olması, Cloud ortamının internet erişimi ayarından ayrıdır. Yürütme kapsamı hakkında ayrıntılı bilgi için Ajan güvenliği yürütme denetimlerine bakın.

Ağ ilkesi önceliği ve çalışma zamanı sınırları

Belirli bir ilke içinde en yüksekten en düşüğe sıralama şöyledir: işletim sistemine özgü ortam geçersiz kılması → tüm işletim sistemleri için ortam geçersiz kılması → Global. Daha düşük öncelikli ilke daha özel olsa bile, daha yüksek öncelikli ilke üstün gelir. Bazı gereksinimlerin alana özgü birleştirme kuralları vardır. Ardından çalışma zamanı, çözümlenen gereksinimleri uygular. Aşağıdaki alana özgü ağ durumlarını ilke önceliğinden ayrı değerlendirin.

Bu örnekler, yönetilen ağın önceden yapılandırıldığı ve daha yüksek öncelikli bir ilkenin değerleri değiştirmediği durumda, aynı ilke içindeki ortam ve Global ayarlarını karşılaştırır. Alana özgü birleştirme ve çalışma zamanı davranışını açıklar.

Ortama göre farklı alan adı erişimi ayarlayın

Bir ilke içindeki aynı alan adı kuralı için, yöneticinin tanımladığı bir ortam geçersiz kılması Global'de reddedilen bir alan adına izin verebilir veya Global'de izin verilen bir alan adını reddedebilir. Ortam geçersiz kılması yoksa Global kuralı devralınır. Diğer geçerli Deny kuralları veya erişim denetimleri bir isteği yine de engelleyebilir.

Alan adı kuralları nasıl birleştirilir?

Bu sonuçlar, daha yüksek öncelikli bir ilkenin sonucu değiştirmediği durumda, bir ilke içindeki aynı alan adı anahtarını karşılaştırır. Daha yüksek öncelikli bir değer, aynı anahtarın değerinin yerini alır. Devralınan diğer anahtarlar korunur. Bir Allow, devralınan bir joker karakter kuralı gibi eşleşen farklı bir Deny kuralını atlamaz. Boş bir ortam eşlemesi, devralınan kuralları temizlemez.

Örnek: Global'de packages.example.com alan adını reddedin ve Development'ta buna izin verin. Development, yukarıdaki koşullar altında buna izin verebilir. Geçersiz kılınmadıkça Production, Global'deki Deny kuralını devralır.

Dağıtılan yürütücünün bu birleştirme kurallarını desteklediğini doğrulayın. Normal yönetilen yürütücülerdeki kapsamın hâlâ doğrulanması gerekir.

Orchestrator sınırları. Yönetilen HTTP/SOCKS dinleyici bağlantı noktaları ve geri döngü dışındaki adreslerde çalışan proxy dinleyicileri, bulut çalışma zamanı tarafından desteklenmez; soket kurallarının desteği yürütme yoluna bağlıdır. Aşağıdaki tabloda yer alan bir yerel yürütme ayarı, desteklenen bir Orchestrator yapılandırması değildir.

Diğer ağ çalışma zamanı sınırları

Aşağıdaki tüm alan adları, experimental_network bölümünde, requirements.toml dosyasında yer alır. Oklar, aynı ilke içindeki bir Global değerini ve ardından gelen ortam değerini gösterir. Bu yerel yürütme durumları, aynı ayarların Orchestrator tarafından desteklendiğini göstermez.

Proxy etkinleştirme, yalnızca izin verilenlerle sınırlama, üst proxy davranışı ve Unix soketi kuralları yürütücüye özgü davranışlar gösterir. Alan adı anahtarlarının birleştirilmesini bu ayarlara genellemeyin. Geçerli değerleri doğrulayın ve dağıtılan çalışma zamanını test edin. Codex Cloud yerel/özel ağ bağlantısı için Ağ erişimi gereksinimlerini yapılandırma bölümüne bakın.

Kullanıma almadan önce davranışı doğrulayın

İş akışlarınızın kullandığı gerçek hedefleri, yerel dinleyicileri, proxy davranışını ve soket yollarını test edin. Etkilenen her ortamda başarılı olması gereken bir eylemi ve engellenmesi gereken bir eylemi kontrol edin. Dağıtılan çalışma zamanı sürümünün kullandığınız her ayarı desteklediğini kontrol edin.

Masaüstü uygulamasının ağ hedeflerini denetleme

Masaüstüne özgü bu gereksinimleri Global'de yapılandırmak için Agent Security bölümündeki Edit as TOML seçeneğini kullanın. Network use controls arayüzü, ayrı bir ilke olan komut ağ erişimini yönetir.

Masaüstü uygulamasının ağ hedeflerini kısıtlamak için [application.network] bölümünü requirements.toml dosyasında kullanın. enabled = true ayarıyla dış isteklerin HTTPS veya WSS kullanması ve tam olarak eşleştiği alan adının "allow" değerini [application.network.domains] bölümünde taşıması gerekir. Alt alan adlarına kendiliğinden izin verilmez. Boş bir alan adı eşlemesi hiçbir dış hedefe izin vermez. Desteklenen anahtarlar için Yapılandırma Başvurusu sayfasına bakın.

Bu politika, komutların ağ erişimi ve tarayıcı kaynak kurallarından ayrıdır. Yerel modüllere veya başlatılan süreçlere hedef kısıtlamaları getirmez ve Work Cloud'da yürütmeyi düzenlemez.

Eklentileri ve yönetilen kancaları yapılandırın

Bu görevler için Agent Security bölümündeki Edit as TOML seçeneğini veya desteklenen bir yerel yapılandırma kaynağını kullanın. Eklenti pazarı varsayılanları, zorunlu eklenti kısıtlamaları ve yönetilen kancalar farklı amaçlara hizmet eder; ihtiyaç duyduğunuz ilkeye uygun görevi seçin.

Eklenti pazarlarını ve varsayılanları yapılandırın

Global config.toml belgesinde yerel veya Git tabanlı eklenti pazarlarını ve eklenti varsayılanlarını tanımlamak için Agent Security > Edit as TOML yolunu kullanın. Ayrıca bu ayarları sistem config.toml dosyasıyla dağıtabilirsiniz. Bunlar zorunlu bir ilke yerine başlangıçtaki eklenti pazarı ve eklenti yapılandırmasını sağlar. Üyelerin kullanabileceği kaynakları sınırlamak için eklenti pazarı kaynağı gereksinimlerini yapılandırın.

Yapılandırma anahtarları için Yapılandırma Başvurusuna, geçersiz kılmalar için Yapılandırma önceliğine ve proje düzeyindeki yapılandırma için depo eklenti ayarlarına bakın. Çalışma alanında GitHub içe aktarma ve eşitleme ayrı bir işlemdir.

Eklenti kullanılabilirliğini denetleme

Global requirements.toml içindeki zorunlu eklenti özelliği ayarları için Agent Security bölümündeki Edit as TOML seçeneğini kullanın veya bu ayarları cihaz yönetimine tabi istemcilere yerel gereksinimler aracılığıyla dağıtın. Defaults > Apps and tools > Apps/connectors uygulama araçlarının varsayılanlarını belirler; zorunlu features.plugins anahtarı değildir. Çalışma alanı eklenti izinleri için Uygulamalar ve bağlayıcılar bölümüne bakın.

Desteklenen yerel istemcilerde eklentileri kapatmak için requirements.toml içinde features.plugins değerini false olarak ayarlayın:

features.plugins = false

Bu ayar, kullanıcılar Codex'te bir API key ile oturum açtığında da uygulanır. Desteklenen yapılandırma için features.plugins referansına bakın.

Eklenti pazar yeri kaynaklarını kısıtlama

Market kaynağı gereksinimlerini Global requirements.toml içinde yapılandırmak için Edit as TOML seçeneğini kullanın veya bunları yerel gereksinimler aracılığıyla iletin. Bu kurallar, kullanıcıların ekleyip kullanabileceği yerel kaynakları veya Git kaynaklarını sınırlar. Bunlar, market varsayılanlarından ayrıdır.

Eklenti pazaryeri kaynaklarını kısıtlamak için restrict_to_allowed_sources = true ayarını yapın ve bir veya daha fazla kaynak kuralı tanımlayın:

[marketplaces]
restrict_to_allowed_sources = true

[marketplaces.allowed_sources.company_plugins]
source = "git"
url = "https://github.com/example/company-plugins.git"
ref = "main"

[marketplaces.allowed_sources.internal_git]
source = "host_pattern"
host_pattern = '^git\.example\.com$'

[marketplaces.allowed_sources.local_plugins]
source = "local"
path = "/opt/company/codex-plugins"

Git kuralları normalleştirilmiş depo URL'siyle ve mevcut olduğunda tam bir ref ile eşleşir. Ana makine kalıpları, küçük harfe dönüştürülmüş Git ana makinesiyle eşleştirilen düzenli ifadelerdir; tüm ana makineyi eşleştirmek için ^ ve $ kullanın. Yerel kurallar mutlak, normalleştirilmiş bir yol gerektirir. Tam şema ve birleştirme davranışı için requirements.toml referansına bakın.

Bu gereksinimler, kurallarla eşleşmeyen pazaryeri ekleme, eklenti yükleme ve yapılandırılmış Git pazaryerlerini yenileme işlemlerini reddeder. Ayrıca yapılandırılmış pazaryerlerini ve bunların eklentilerini çalışma zamanında filtreler.

API key kataloğu dahil, OpenAI tarafından seçilip düzenlenen Git pazaryerleri de kaynak izin listesiyle eşleşmelidir. Bunlara izin vermek için aşağıdaki Git kaynağını ref kısıtlaması olmadan ekleyin:

[marketplaces.allowed_sources.openai_curated]
source = "git"
url = "https://github.com/openai/plugins.git"

Seçilip düzenlenen katalogları hariç tutmak için bu kaynağı eklemeyin ve daha geniş kapsamlı hiçbir ana makine kuralının buna izin vermediğinden emin olun. Birlikte sunulan eklentiler ve uzaktan yüklenen çalışma alanı eklentileri, seçilip düzenlenen Git kaynaklarına ilişkin bu ilkeden ayrıdır.

Bu kaynak kısıtlamaları yalnızca yerel bir istemcinin eklenti pazar yeri işlemlerini desteklediği yerlerde geçerlidir: masaüstü uygulamasındaki ChatGPT ve Codex ile Codex CLI. ChatGPT'nin web veya mobil sürümünde eklenti kullanımını denetlemez ve IDE uzantısına eklenti eklemez.

Yönetilen kancaları gereksinimler aracılığıyla zorunlu kılın

Yönetilen kancalar, desteklenen görev veya araç olaylarında yöneticinin tanımladığı eylemleri çalıştırır. Bunları Global requirements.toml içinde yapılandırmak için Agent Security bölümündeki Edit as TOML seçeneğini kullanın; ayar denetimlerinde özel bir kanca düzenleyicisi bulunmaz. Aşağıdaki yürütme yolları, hangi kanca türlerinin çalışabileceğini belirler.

Yönetilen ilke ve uzak kancalar etkinleştirildiğinde, yerel erişimli Work Cloud ve dots, bulut orkestratöründe yönetici tarafından yönetilen uzak MCP kancalarını kullanır. mcp_tool işleyicilerini Global requirements.toml içinde yapılandırın. Yerel erişimi olmayan Work Cloud ve kişisel hesaplar bu kurumsal kancaları kullanmaz. Komut/kabuk, prompt ve ajan işleyicileri; yerel yapılandırmadan, eklentilerden veya yerel dizinlerden gelen kancalar; ortam kapsamlı kancalar ve SessionEnd MCP kancaları, araçlar yerel olarak yürütülse bile bulut orkestrasyonunda desteklenmez. Hem orkestrasyon hem de yürütme yerel olduğunda, desteklenen mevcut kancalar yalnızca yerelde çalışan Work ve Codex konuşmalarında çalışmaya devam eder. Yöneticiler bu iş akışları için desteklenen yönetilen kancaları Agent Security bölümünde yapılandırmaya devam edebilir.

Bu kancalara güvenmeden önce geri çağrı bağlantısını, gerekli olayları ve hata durumundaki davranışı test edin. Desteklenen açık bir ret yanıtı bir eylemi engelleyebilir; ancak PreToolUse geri çağrısındaki bir hata, zaman aşımı veya hatalı biçimlendirilmiş yanıt, aracı engellemeden kancanın başarısız olmasına neden olabilir. MCP kancaları eksiksiz bir Compliance API denetim izi sağlamaz. Aşağıdaki betik ve dizin örnekleri Codex kapsamını korur.

Yöneticiler, yönetilen yaşam döngüsü kancalarını doğrudan requirements.toml içinde de tanımlayabilir. Kanca yapılandırmasının kendisi için [hooks] kullanın ve managed_dir değerini, MDM veya uç nokta yönetim araçlarınızın başvurulan betikleri yüklediği dizine yönlendirin.

Kancaları yerel olarak kapatan kullanıcılar için bile yönetilen kancaları zorunlu kılmak üzere [features].hooks = true değerini [hooks] ile birlikte sabitleyin. Yönetilen kancalara izin vermeye devam ederken kullanıcı, proje, oturum ve eklenti kancalarını atlamak için allow_managed_hooks_only = true ayarını yapın.

allow_managed_hooks_only = true

[features]
hooks = true

[hooks]
managed_dir = "/enterprise/hooks"
windows_managed_dir = 'C:\enterprise\hooks'

[[hooks.PreToolUse]]
matcher = "^Bash$"

[[hooks.PreToolUse.hooks]]
type = "command"
command = "python3 /enterprise/hooks/pre_tool_use_policy.py"
command_windows = 'py -3 C:\enterprise\hooks\pre_tool_use_policy.py'
timeout = 30
statusMessage = "Checking managed Bash command"

Notlar:

• Yerel çalışma zamanı, requirements.toml içindeki kanca yapılandırmasını uygular, ancak managed_dir içindeki betikleri dağıtmaz.
• Bu betikleri MDM veya cihaz yönetimi çözümünüzle dağıtın.
• Yönetilen kanca komutları, yapılandırılmış yönetilen dizin altındaki mutlak betik yollarına başvurmalıdır.
• allow_managed_hooks_only = true kullanıcı, proje, oturum ve eklenti kaynaklarından gelen kancaları atlar, ancak requirements.toml ve diğer yönetilen yapılandırma katmanlarındaki kancaları yüklemeye devam eder.

İlke kapsamını ve önceliğini anlayın

Bir ilkenin nerede geçerli olduğunu, gereksinimlerin nasıl birleştirildiğini, istemcilerin buluttan yönetilen ayarları nasıl aldığını ve sonucun nasıl doğrulanacağını kontrol etmek için bu bölümü kullanın.

Yerel erişimli Work ve dots için yönetilen ilke etkinleştirildiğinde, desteklenen Global ilkesi paylaşılan bulut orkestratörünü yönetir; geçerli yerel yürütme gereksinimleri ise bağlı bilgisayarı yönetir. Work bulut kapsayıcıları mevcut Work Cloud ilkelerini korur ve desteklenen cihaz denetimleri yerel yürütmede geçerliliğini sürdürür. Codex mevcut yapılandırma davranışını korur. Yönetilen yapılandırma, çalışma alanında kullanıcı lisansı veya özellik erişimi sağlamaz. Bu denetimler için Roller ve çalışma alanı izinleri bölümünü kullanın.

Agent Security ve Work Cloud ile yerel bilgisayar erişimi

İlkeleri ve yapılandırmayı yönetmek için Admin Console içindeki Agent Security bölümünü kullanın. Bu bölüm, Policies & Configuration bölümünün yerini alır. Agent Security, Work Cloud ile yerel bilgisayar erişiminden bağımsız olarak Admin Console içinde kullanılabilir. Mevcut ilkeler, atamalar ve sıralama korunur. Mevcut ilkelerinizi Agent Security bölümünde gözden geçirin. Work Cloud ile yerel bilgisayar erişimi ayrıca etkinleştirilmesi gereken bir seçenektir. Geçiş yönergeleri için Agent Security bölümüne bakın.

İlke otomasyonunu Agent Security bölümüne taşımadan önce:

1. Etkilenen entegrasyonları belirleyin. İlkeleri güncelleyen Terraform yapılandırmalarının ve betiklerin envanterini çıkarın ve hangi ilkeleri yönettiklerini kaydedin.

2. Global ayarlarını yönetmek için ilke API'sini kullanın. Local veya Codex Cloud ayarlarını yönetmek için Agent Security kullanıcı arayüzünü kullanın. Mevcut Global API iş akışları geçişten sonra da kullanılabilir. Betiklerinizi ve Terraform entegrasyonlarınızı test edin; ilke atamalarının ve sıralamanın değişmediğini doğrulayın.

3. Gerekli değişiklikleri yapın ve otomasyonu test edin. Amaçlanan güncellemenin doğru Agent Security ilkesine ulaştığını ve ortaya çıkan denetimlerin uygulandığını doğrulayın.

İlke geçişi, Work veya dots için yerel bilgisayar erişimi sağlamaz. Kullanıma sunmadan önce ilkeleri gözden geçirmeniz veya oluşturmanız önerilir; ancak onay akışı, erişimi etkinleştirmek için ilke oluşturulmasını gerektirmez. Allow local computer access seçeneğini etkinleştirmeden önce, geçişi yapılan temel yapılandırmayı gözden geçirin veya ilkeleriniz şu anda yalnızca MDM aracılığıyla iletiliyorsa bulutta bir temel yapılandırma oluşturun. Herhangi bir bulut ilkesinde enforce_residency etkinse, Allow local computer access hem Work hem de dots için devre dışı bırakılır. Bu koruma önlemi, çalışma alanının veri yerleşimini yapılandırmaz veya tek başına Work Cloud ya da dots hizmetini devre dışı bırakmaz.

Ortam geçersiz kılmaları, bir ilke içindeki desteklenen ayarları ortama göre değiştirir. Belirli bir ilkede en yüksekten en düşüğe doğru sıralama şöyledir: işletim sistemine özgü ortam geçersiz kılması → tüm işletim sistemleri için ortam geçersiz kılması → Global. Daha düşük öncelikli ilke daha özel olsa bile daha yüksek öncelikli ilke geçerli olur. Bazı gereksinimlerin alana özgü birleştirme kuralları vardır. Çalışma alanınızda hangi geçersiz kılma düzenleyicilerinin ve alanlarının kullanılabildiğini doğrulayın.

Yönetilen ilke ve uzak kancalar etkinleştirildiğinde, yerel erişimli Work Cloud ve dots, bulut orkestratöründe yönetici tarafından yönetilen uzak MCP kancalarını kullanır. mcp_tool işleyicilerini Global requirements.toml içinde yapılandırın. Yerel erişimi olmayan Work Cloud ve kişisel hesaplar bu kurumsal kancaları kullanmaz. Komut/kabuk, prompt ve ajan işleyicileri; yerel yapılandırmadan, eklentilerden veya yerel dizinlerden gelen kancalar; ortam kapsamlı kancalar ve SessionEnd MCP kancaları, araçlar yerel olarak yürütülse bile bulut orkestrasyonunda desteklenmez. Hem orkestrasyon hem de yürütme yerel olduğunda, desteklenen mevcut kancalar yalnızca yerelde çalışan Work ve Codex konuşmalarında çalışmaya devam eder. Yöneticiler bu iş akışları için desteklenen yönetilen kancaları Agent Security bölümünde yapılandırmaya devam edebilir. Bu kancalara güvenmeden önce geri çağrı bağlantısını, gerekli olayları ve hata durumundaki davranışı test edin. Desteklenen açık bir ret yanıtı bir eylemi engelleyebilir; ancak PreToolUse geri çağrısındaki bir hata, zaman aşımı veya hatalı biçimlendirilmiş yanıt, aracı engellemeden kancanın başarısız olmasına neden olabilir. MCP kancaları eksiksiz bir Compliance API denetim izi sağlamaz. Yapılandırma Başvurusu bölümüne bakın.

Konumlar ve öncelik

Yerel yürütmede gereksinimler, düşük öncelikten yüksek önceliğe doğru aşağıdaki sırayla uygulanır. Bu sıralama, Work Cloud ile yerel bilgisayar erişimindeki yerel adımlar için de geçerlidir:

1. Sistem requirements.toml dosyası (Linux ve macOS dahil Unix sistemlerinde /etc/codex/requirements.toml, Windows'ta ise %ProgramData%\OpenAI\Codex\requirements.toml konumundadır).
2. Bulut yapılandırma paketiyle iletilen Agent Security gereksinimleri.
3. Yerel istemcinin gereksinim olarak yeniden yorumladığı eski managed_config.toml alanları.
4. Şu ayar aracılığıyla iletilen macOS yönetilen tercihleri (MDM): com.openai.codex:requirements_toml_base64.

Daha yüksek öncelikli katmanlar, alt katmanlardaki normal skaler ve liste değerlerini geçersiz kılar. Tablolar anahtara göre birleştirilirken kurallar, kancalar ve dosya sistemi kısıtlamaları gibi gereksinimler alana özgü bileşim davranışı gösterir. Güncel şema için requirements.toml başvurusunu kullanın; her alanın aynı şekilde birleştirildiğini varsaymayın.

Geriye dönük uyumluluk için desteklenen yerel istemciler, eski approval_policy, approvals_reviewer ve sandbox_mode alanlarını gereksinim olarak yeniden yorumlar. Bu dönüşüm, gerektiğinde uyumluluk seçenekleri ekler; açık izin listeleri için requirements.toml kullanın.

Work Cloud ile yerel bilgisayar erişiminde öncelik

Yerel erişimli Work ve dots için Global orkestratör ilkesini yürütme ilkesinden ayırın. Geçerli yerel gereksinimler bağlı bilgisayarı yönetir. Work bulut kapsayıcıları ve dots bulut bilgisayarları, diğer yürütücülerin kullandığı yönetilen ortam paketi yerine kendi yürütme yapılandırmalarını ve gereksinimlerini kullanır.

Yerel yürütmede MDM ve eski yönetilen cihaz gereksinimleri, Agent Security'den daha yüksek önceliğe sahiptir. Cihazın sistem gereksinimleri dosyası ise Agent Security'den daha düşük önceliğe sahiptir. Her ilkede önce işletim sistemine özgü ortam geçersiz kılmalarını, ardından tüm işletim sistemleri için ortam geçersiz kılmalarını, son olarak Global ayarlarını çözümleyin. İlkeler arasında ilke önceliği, özgüllükten üstündür.

Gereksinimler kısıtlamalar getirirken yapılandırma varsayılanları başlangıç değerlerini sağlar. Yerel erişimli Work ve dots için, yönetilen ilke etkinleştirildiğinde desteklenen Global ilkesi paylaşılan bulut orkestratörü üzerinden uygulanır. Geçerli yerel requirements.toml gereksinimleri, bağlı bir bilgisayardaki yürütmeyi yönetir. Work bulut kapsayıcıları ve dots bulut bilgisayarları, diğer yürütücü türlerinin kullandığı yönetilen ortam paketi yerine kendi yürütme yapılandırmalarını ve gereksinimlerini kullanır. Yerel yürütme kısıtlamaları bu bulut bilgisayarlarına otomatik olarak uygulanmaz. Bulut yetenek izinlerini gözden geçirin ve yerel yürütme ile bulut yürütmesini ayrı ayrı test edin.

Onaylar ve web araması dahil orkestratör denetimlerini Global içinde tutun. Kullanılabildiği yerlerde özel Allowed approval policies ve Allowed web search modes denetimlerini, desteklenen diğer alanlar için ise TOML kullanın. Alan listesi ve yürütme kapsamı için Yapılandırma Referansı bölümüne bakın.

Buluttan yönetilen gereksinimler

Bir kullanıcı desteklenen bir planda ChatGPT ile oturum açtığında, desteklenen yerel istemciler çalışma alanıyla ilişkili, yönetici tarafından zorunlu kılınan gereksinimleri alabilir. Bu, requirements.toml ile uyumlu ilkeler için bir dağıtım kanalıdır. Çalışma alanına erişim sağlamaz veya çalışma alanının RBAC sisteminin yerini almaz. Kimlik doğrulama gereksinimleri yerel olarak yönetilmelidir.

Ortak gereksinimleri ajan güvenliği denetimleri ile yapılandırın. Yalnızca istek üzerine onaylara ve salt okunur veya çalışma alanına yazma korumalı alanlarına izin veren bir ilke için Policy guardrails altındaki Approval policies ve Sandbox modes seçeneklerini kullanın. Ayrıca desteklenen bir kabuk giriş noktası çalıştırılmadan önce onay istenmesi için Edit as TOML seçeneğini kullanarak [rules] tablosunu Global requirements.toml dosyasına ekleyin.

Tam TOML karşılığı şöyledir:

allowed_approval_policies = ["on-request"]
allowed_sandbox_modes = ["read-only", "workspace-write"]

[rules]
prefix_rules = [
  { pattern = [{ any_of = ["bash", "sh", "zsh"] }], decision = "prompt", justification = "Require explicit approval for shell entry points" },
]

Yönetilen her istemci sürümünün seçtiğiniz anahtarları desteklediğini kontrol edin. İlkeyi hedeflenen kullanıcılara veya gruplara atayın ve desteklenen istemcilerinde etkili olduğunu doğrulayın. Güncel şema için yapılandırma referansını, güncel atama davranışı için ise yönetim arayüzünü kullanın.

Hizmet, oturum açmış kimlik için geçerli olan, kurum tarafından yönetilen gereksinim katmanlarını seçer. Yerel istemci bu katmanları, Konumlar ve öncelik bölümünde açıklanan diğer gereksinim kaynaklarıyla birlikte değerlendirir. Çalışma alanı tarafındaki oluşturma ve atama işlemleri için güncel yönetim arayüzünü kullanın. Kopyalanmış bir grup eşleştirme algoritmasına güvenmeyin; bu davranışı yönetim hizmeti belirler ve yerel gereksinim biçiminden bağımsız olarak değiştirebilir.

Desteklenen anahtarlar ve örnekler için Örnek requirements.toml ve requirements.toml referansı bölümlerine bakın.

Yerel istemciler buluttan yönetilen gereksinimleri nasıl uygular?

Aşağıdaki yerel yükleme ve önbellek davranışı, desteklenen yerel istemcileri açıklar. Work Cloud ile yerel bilgisayar erişimini kullanan ve zaten çalışan bir görevde, değiştirilmiş bir bulut ilkesinin ne zaman etkili olacağını belirlemez. Değiştirilmiş bir kısıtlamaya güvenmeden önce geçerli ilkeyi doğrulayın.

Bir kullanıcı desteklenen bir yerel istemciyi başlatıp desteklenen bir planda ChatGPT ile oturum açtığında, istemci önce kimlikle eşleşen geçerli bir önbellek kaydı olup olmadığını kontrol eder. Geçerli bir kayıt yoksa istemci ilgili paketi yeniden denemelerle alır ve başarılı olduğunda imzalı bir önbellek kaydı yazar. İstek başarısız olur veya zaman aşımına uğrarsa ve geçerli bir önbellek yoksa bulut yapılandırma paketinin yüklenmesi, buluttan yönetilen gereksinimler katmanı olmadan sessizce başlamak yerine hata döndürür.

Önbellek çözümlemesinden sonra istemci, bulut gereksinimlerini yukarıda açıklanan diğer gereksinim katmanlarıyla birleştirir. Arka plandaki bir yenileme, önbelleğe alınmış paketi günceller ve sonraki yapılandırma yüklemelerinde kullanılabilir hale getirir. Bu, zaten çalışan bir görevin değiştirilmiş bir ilkeyi hemen kullanacağını garanti etmez. Bazı masaüstü ayarları uygulamanın yeniden başlatılmasını gerektirir; yeniden başlatma istemlerini izleyin ve değişikliğe güvenmeden önce geçerli ayarları doğrulayın.

Yönetici ve çalışan deneyimini doğrulayın

Yönetilen her ilke için bir sorumlu atayın, hangi kullanıcıların veya grupların ilkeyi alması gerektiğini kaydedin ve her dosya sistemi, ağ, onay veya izin profili kısıtlamasının iş gerekçesini belgeleyin.

Hedeflenen izinlere sahip bir kullanıcıyla izin verilen bir iş akışını ve engellenen bir iş akışını test edin. Desteklenen istemcide geçerli ayarları kontrol edin. Bir çalışma alanı rolü veya grubu tek başına yerel çalışma zamanı kısıtlamasını uygulamaz.

Bir üye, grup veya rol seçimiyle hangi ilkelerin eşleştiğini kontrol etmek için Agent Security içindeki Test policies seçeneğini kullanın. Düzenlenebilir bir oturumda bu işlem, mevcut taslağı kaydetmeden kontrol eder. Sonuç, son birleştirilmiş yapılandırmayı veya bir istemcinin kısıtlamayı uygulayıp uygulamadığını değil, ilke seçimini gösterir. Kaydettikten sonra ilgili her istemcide ve yürütme yolunda izin verilen ve engellenen iş akışlarını test edin.

Cihazdan yönetilen yapılandırmayı dağıtın

Kimlik doğrulama kısıtlamaları ve cihazdan yönetilen ilkeler için yerel sistem gereksinimlerini veya MDM kullanın. Eski managed_config.toml mekanizmasının başlangıç önceliği, Agent Security Defaults ayarlarınınkinden farklıdır. MDM iş akışı hem gereksinimleri hem de eski varsayılanları kapsar.

Kimlik doğrulamayı yerel olarak yönetin

allowed_login_methods, allowed_chatgpt_workspaces, cli_auth_credentials_store ve chatgpt_base_url alanlarını yerel sistemin requirements.toml dosyasında veya macOS MDM gereksinimlerinde ayarlayın. Codex bu dört alanı buluttan yönetilen gereksinimlerde yok sayar. Yerel kimlik doğrulama gereksinimleri, kimlik bilgileri yüklenmeden ve Codex bulut ilkesini almadan önce uygulanır.

Onaylanmış bir çalışma alanında ChatGPT ile oturum açmayı zorunlu kılmak ve kimlik bilgilerini işletim sisteminin kimlik bilgisi deposunda saklamak için şunu kullanın:

allowed_login_methods = ["chatgpt"]
allowed_chatgpt_workspaces = ["00000000-0000-0000-0000-000000000000"]
cli_auth_credentials_store = "keyring"

allowed_login_methods, chatgpt, api veya her ikisini kabul eder. Belirtilmezse bu ayar oturum açma yöntemlerini kısıtlamaz. Ayarlanırsa liste en az bir yöntem içermelidir. api, Amazon Bedrock dahil API kimlik doğrulamasına izin verir. Çalışma alanı kısıtlaması Codex erişim belirteçleri için de geçerlidir.

Kullanıcının yapılandırdığı forced_login_method ve forced_chatgpt_workspace_id gereksinimlere uymalıdır. Kullanıcı bir çalışma alanı seçtiğinde bu alanın yönetilen çalışma alanı izin listesinde de bulunması gerekir. Eşleşen çalışma alanı yoksa ChatGPT ile oturum açma kullanılamaz. İzin verildiğinde API kimlik doğrulaması kullanılabilir durumda kalır. Kullanılabilir bir oturum açma yöntemi yoksa Codex başlamayı reddeder.

Kimlik bilgisi saklama modları ve hizmet URL'si yapılandırması için gereksinimler referansı bölümüne bakın.

Yönetilen varsayılanlar (managed_config.toml)

Desteklenen, buluttan yönetilen başlangıç değerleri için Agent Security Defaults seçeneğini kullanın. Bu bölüm, cihazdan yönetilen eski managed_config.toml mekanizmasını ve farklı başlangıç önceliğini kapsar. Agent Security içindeki Defaults ayarlarını düzenlemek, üyelerin cihazlarına bir managed_config.toml dosyası dağıtmaz.

Yönetilen varsayılanlar, desteklenen bir yerel istemcinin başlangıçta kullanacağı yapılandırmayı belirler. İstemci başlatılırken kullanıcının yerel config.toml değerini ve tüm CLI --config geçersiz kılmalarını geçersiz kılar. Kullanıcılar geçerli çalıştırma sırasında bu ayarları yine değiştirebilir ve istemci bir sonraki kez başlatıldığında varsayılanlar yeniden uygulanır.

GPT-5.5, 14 Ekim 2026'da Pasifik Yaz Saati ile öğlen 12.00'de (19.00 UTC) ChatGPT ile oturum açılan Codex'ten kaldırılacaktır. Yönetilen bir varsayılan, macOS MDM profili veya kaydedilmiş yapılandırma bu kullanıcılar için gpt-5.5 değerini sabitliyorsa bunu kullanılabilir bir modelle değiştirin. Bir yönetici etkilenen kullanıcılar için etkinleştirdikten sonra gpt-6.1-sol seçeneğini belirleyin. OpenAI API ve API key ile kimliği doğrulanmış Codex oturumları bundan etkilenmez. Çalışma alanında model kullanılabilirliği bölümüne bakın.

Hâlâ gpt-5.4 veya gpt-5.4-mini modelini sabitleyen yapılandırmalar için GPT-5.4 geçiş yönergelerini izleyin.

Yönetilen varsayılanlarınızın gereksinimlerinizi karşıladığından emin olun; yerel çalışma zamanı izin verilmeyen değerleri reddeder.

Öncelik ve katmanlama

Yerel çalışma zamanı etkin yapılandırmayı şu sırayla oluşturur (üstteki alttakini geçersiz kılar):

• Yönetilen tercihler (macOS MDM; en yüksek öncelik)
• managed_config.toml (sistem/yönetilen dosya)
• config.toml (kullanıcının temel yapılandırması)

CLI --config key=value geçersiz kılmaları temele uygulanır, ancak yönetilen katmanlar bunları geçersiz kılar. Bu, yerel bayraklar sağlasanız bile her çalışmanın yönetilen varsayılanlardan başladığı anlamına gelir.

Buluttaki config.toml, normal yapılandırma önceliğini kullanır; yukarıdaki eski sıralamayı kullanmaz. Buluttaki requirements.toml ise gereksinim önceliğini kullanır.

Konumlar

• Linux/macOS (Unix): /etc/codex/managed_config.toml
• Windows/Unix dışı: ~/.codex/managed_config.toml

Dosya yoksa yerel çalışma zamanı yönetilen katmanı atlar.

Örnek managed_config.toml

# Set conservative defaults
approval_policy = "on-request"
sandbox_mode    = "workspace-write"

[sandbox_workspace_write]
network_access = false             # keep network disabled unless explicitly allowed

[otel]
environment = "prod"
exporter = "otlp-http"            # point at your collector
log_user_prompt = false            # keep prompts redacted
# exporter details live under exporter tables; see Monitoring and telemetry above

Önerilen koruyucu önlemler

• Çoğu kullanıcı için onaylarla birlikte workspace-write kullanmayı tercih edin; tam erişimi kontrollü kapsayıcılarla sınırlayın.
• Güvenlik incelemeniz bir toplayıcıya veya iş akışlarınızın gerektirdiği alan adlarına izin vermedikçe network_access = false ayarını koruyun.
• OTel ayarlarını (dışa aktarıcı, ortam) sabitlemek için yönetilen yapılandırmayı kullanın; ancak politikanız prompt içeriklerinin saklanmasına açıkça izin vermedikçe log_user_prompt = false ayarını koruyun.
• Sapmaları tespit etmek için yerel config.toml ile yönetilen politika arasındaki farkları düzenli olarak denetleyin; yönetilen katmanlar yerel bayraklara ve dosyalara göre öncelikli olmalıdır.

macOS yönetilen tercihleri (MDM)

macOS'ta yöneticiler, base64 ile kodlanmış TOML yüklerini şu konumda sağlayan bir cihaz profili gönderebilir:

• Tercih alanı: com.openai.codex
• Anahtarlar:
  • config_toml_base64 (yönetilen varsayılanlar)
  • requirements_toml_base64 (gereksinimler)

Yerel çalışma zamanı bu "yönetilen tercihler" yüklerini TOML olarak ayrıştırır. Yönetilen varsayılanlar (config_toml_base64) için yönetilen tercihler en yüksek önceliğe sahiptir. Gereksinimler (requirements_toml_base64) için öncelik, gereksinim sırasına göre belirlenir. Gereksinimler tarafındaki aynı [features] tablosu requirements_toml_base64 içinde de çalışır; burada da kanonik özellik anahtarlarını kullanın.

MDM kurulum iş akışı

Yerel çalışma zamanı standart macOS MDM yüklerini destekler; dolayısıyla ayarları Jamf Pro, Fleet veya Kandji gibi araçlarla dağıtabilirsiniz. Hafif bir dağıtım şöyle görünür:

1. Yönetilen yük TOML'sini oluşturun ve base64 ile kodlayın (satır kaydırma olmadan).
2. Dizeyi MDM profilinizde com.openai.codex alanı altındaki config_toml_base64 (yönetilen varsayılanlar) veya requirements_toml_base64 (gereksinimler) konumuna bırakın.
3. Profili gönderin, ardından kullanıcılardan desteklenen yerel istemciyi yeniden başlatmalarını ve başlangıç yapılandırması özetinin yönetilen değerleri yansıttığını doğrulamalarını isteyin.
4. Politikayı iptal ederken veya değiştirirken yönetilen yükü güncelleyin; istemci yenilenmiş tercihi bir sonraki başlatılışında okur.

Yüke gizli bilgiler veya sık değişen dinamik değerler yerleştirmekten kaçının. Yönetilen TOML'yi değişiklik denetimi altındaki diğer MDM ayarları gibi ele alın.