@@ -119,11 +119,13 @@ launch or exec. They do not add filesystem grants or parent directory access and
 do not require `read_write` entries, regardless of mount flags. Communication
 uses the existing Unix IPC and socket permission checks.
 
-Ordinary writable CDI mount destinations are fail-closed. OpenShell accepts a writable
-CDI mount only when it targets a single file and that exact path is already
-listed in `filesystem_policy.read_write`. Writable CDI directory mounts and CDI
-paths such as `/`, `/dev`, `/proc`, `/sys`, `/run`, or `/usr` are rejected
-during sandbox startup.
+Ordinary CDI file and directory mounts must be effectively read-only. OpenShell
+rejects writable mounts even when `filesystem_policy.read_write` names their
+exact destination or an ancestor. Explicit authorization for CDI host writes is
+not currently supported. This restriction does not apply to device nodes or
+Unix socket communication.
+CDI paths such as `/`, `/dev`, `/proc`, `/sys`, `/run`, or `/usr` remain rejected
+during sandbox startup, even when authored policy grants access to those roots.
 
 CDI does not add a blanket `/sys` grant. If an application needs sysfs paths
 that the selected CDI spec does not supply, include those paths in your authored
 
@@ -158,12 +158,14 @@ updated Docker daemon capability.
 For CDI-enabled Docker sandboxes, OpenShell validates the injected filesystem
 targets before each launch and exec. Library directories may use symlinks, but
 must not resolve to broad roots such as `/`, `/usr`, or `/dev`. Device nodes must
-resolve to devices, and ordinary writable mounts must resolve to single files explicitly
-allowed by exact entries in the policy. OpenShell determines mount access from
+resolve to devices. Ordinary file and directory mounts must be effectively
+read-only; writable mounts are rejected even with exact or ancestor authored
+write grants. Explicit authorization for CDI host writes is not currently
+supported. OpenShell determines mount access from
 effective runtime flags, including writable submounts beneath original directory
 mounts. Unix socket mounts retain their exact socket destinations and must resolve
 to sockets at each launch or exec. They do not grant access to parent directories
-or require writable-file policy entries. CDI does not automatically grant write access to `/proc`. The container
+or require writable filesystem grants. CDI does not automatically grant write access to `/proc`. The container
 runtime must supply any supplemental groups required by the CDI spec; missing
 groups prevent workload launch. CDI spec projections are checked with resource
 admission enabled. Invalid CDI targets or unavailable filesystem enforcement
 
@@ -126,7 +126,12 @@ and daemon-reported CDI spec directories to build a workload CDI context. The
 driver embeds the context in the protected boundary configuration and
 projects the spec directories read-only under the protected `/.openshell/cdi-specs`
 hierarchy. These structured binds neither create missing host directories nor
-relabel existing directories. Every daemon-reported directory must exist and be
+relabel existing directories. Before creating a GPU sandbox, OpenShell checks each directory with a temporary,
+stopped container using the prepared workload image. It skips confirmed missing
+directories and records only the available projections. Probe results are cached
+for 30 seconds and refreshed on demand; sandbox creation is not retried.
+At least one directory must remain and every selected device must resolve from
+its specs. Permission errors still fail creation; existing directories must be
 readable under the host's SELinux policy. Agent processes cannot read the
 projections, even with a broad authored filesystem grant. If context
 creation fails, the driver removes the created state. If workload or supervisor
@@ -136,6 +141,16 @@ requirements from CDI specs before launching agent processes. Non-GPU Docker
 sandboxes do not receive the CDI context, spec mounts, or CDI-derived policy
 changes.
 
+Existing Docker GPU containers without CDI context retain the legacy GPU
+filesystem baseline on restart. Admission requires spec projections only when
+the driver-owned boundary configuration contains CDI context, and validates
+those projections against the directories recorded at creation. Missing or
+unreadable boundary configuration blocks restart. To use CDI-derived access on
+an older sandbox, recreate it. Ordinary CDI file and directory mounts must be
+effectively read-only. Filesystem `read_write` grants do not authorize writable
+CDI mounts; explicit authorization for CDI host writes is not currently
+supported. Device nodes and Unix socket communication remain supported.
+
 ### Docker Corporate Proxy Egress
 
 For proxy-required networks, the Docker driver accepts `https_proxy`,