config.toml migration generates a permissions.<name> block that fails --strict-config parsing; sandbox_workspace_write.network_access silently ignored in static config

What version of Codex CLI is running?

codex-cli 0.149.1

What platform is your computer?

Linux (Ubuntu-based), x86_64

What issue are you seeing?

After npm install -g @openai/codex@latest auto-migrated my ~/.codex/config.toml, it wrote a default_permissions = "protect-env" block using the newer [permissions.<name>] profile system:

default_permissions = "protect-env"

[permissions.protect-env]
extends = ":workspace"

[permissions.protect-env.filesystem]
glob_scan_max_depth = 8

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

Running with --strict-config against this exact, unmodified, migration-generated config fails to parse:

Error loading config.toml:
/home/amlan/.codex/config.toml:8:2: data did not match any variant of untagged enum FilesystemPermissionToml
  |
8 | [permissions.protect-env]
  |  ^^^^^^^^^^^

Without --strict-config, this same block is silently ignored — no error, but default_permissions = "protect-env" appears to be a no-op, since sandboxed sessions always fall back to the stock :workspace sandbox defaults (.git read-only, network access disabled) regardless of the profile's contents.

Separately (possibly related, possibly a separate default-change from an update): setting the older/documented

[sandbox_workspace_write]
network_access = true
writable_roots = ["/some/path"]

at the config.toml root (or via a -p profile file) is also silently ignored — no error, no effect on the sandbox's writable roots or network access shown in the session banner. The equivalent -c sandbox_workspace_write.network_access=true CLI override does work at runtime, so there's a discrepancy between how this key is honored via static config-file loading vs. a -c override.

What steps can reproduce the bug?

1. Have Codex CLI auto-update to 0.149.1 (or otherwise obtain a config.toml with a migration-generated [permissions.<name>] block, e.g. via the protect-env deny-.env migration).
2. Run any command with --strict-config, e.g.:

   codex exec --strict-config -c 'default_permissions="protect-env"' "echo hi"
   

3. Observe the parse error on the exact block the migration itself generated:

   data did not match any variant of untagged enum FilesystemPermissionToml
   

4. Separately, confirm sandbox_workspace_write.network_access = true set in config.toml (root level or via -p <profile>.config.toml) has no effect — git fetch/curl inside the sandbox still fail with Could not resolve host, and the session banner doesn't show (network access enabled). The same setting via -c sandbox_workspace_write.network_access=true on the command line does work.

Impact

Since the mismatch is silently swallowed outside --strict-config, users have no visibility that their permissions profile isn't applying — sandboxed sessions just behave as if no custom profile exists, with no error or warning. Given .git is read-only and network is disabled by default under :workspace, this makes basic git fetch/git push/web-search workflows fail with no indication that the intended permissions override never took effect.

The issue names config.toml, the migration-generated [permissions.] block, --strict-config, -p profile loading, and -c overrides; begin by tracing those configuration-loading paths. Reproduce both cases and verify that migrated permission profiles parse under --strict-config and that sandbox_workspace_write settings from static config files affect runtime behavior consistently with -c overrides.