How can I enable network access for only one local Codex Desktop project when custom permission profiles are missing from the picker?

[mzoneren]

I am looking for a supported way to allow persistent network access for one local project while retaining the workspace filesystem sandbox and leaving other projects network-restricted.

Environment: macOS ARM64; desktop version 26.1007.30912; bundled Codex CLI 0.162.0-alpha.17.2.

Minimal project-local configuration (profile name below is generic):

default_permissions = "project-net"

[permissions.project-net]
extends = ":workspace"

[permissions.project-net.network]
enabled = true

The project is marked trusted. There is no user-level network-enabled default. The permission picker offers Ask for approval, Approve for me, and Full access, but neither Custom (config.toml) nor the named project profile.

Observed runtime values, transcribed without raw logs or identifiers:

requestPermissionProfile=:workspace
useAppServerPermissionDefault=false
CODEX_PERMISSION_PROFILE=:workspace
CODEX_SANDBOX_NETWORK_DISABLED=1

A new local task reproduces this. Restarting did not resolve the original task. Direct network access remains restricted. A separate CLI/configuration check is not being treated as proof that Desktop has applied the profile.

This resembles #37437 and #28281, but I need workspace filesystem restrictions with project-specific network access, rather than Full access.

Questions:

1. What is the supported Desktop UI or configuration route for selecting a named project-local permission profile in this version?
2. Can Desktop's permissionProfile/list, config/read, and configRequirements/read results be inspected through a supported diagnostic workflow to identify why the profile is omitted?
3. Is there a known fix or workaround that preserves the sandbox, requires no global network-enabled default, and does not modify managed policy or bypass security controls?

Please do not request credentials or unredacted diagnostic bundles. A sanitized minimal reproduction can be provided if useful.

[tk1475]

I can't see the Desktop app's code, but the app-server side gives a hint. permissionProfile/list takes an optional cwd, and project .codex/config.toml layers only get resolved when it's passed. Your runtime values show Desktop explicitly requesting :workspace, so it looks like it isn't picking up project-scoped profiles at all, whatever default_permissions says in the project file.

The legacy [sandbox_workspace_write] network_access = true route won't help either. When :workspace is selected explicitly, those legacy settings are intentionally ignored.

What I'd try: move the [permissions.project-net] profile into ~/.codex/config.toml without making it the default, restart Desktop, and see if it shows up in the picker so you can select it just for that project. Nothing gets network by default that way.

Running the CLI from that folder and using /debug-config shows which layers actually loaded. If the user-level profile also doesn't show up in Desktop, I'd file it as a bug.

[mzoneren]

Thank you for the helpful explanation and suggestion! After adding the named permission profile to the user-level config without making it the default, it now appears in Desktop’s permission picker. That addresses the missing-profile part of my question.

To distinguish that from the automation outcome: I have not selected the new profile; the conversation still uses Ask for approval. My scheduled email digest is now working through a separate, explicitly installed, project-scoped read-only STDIO MCP server, rather than running IMAP scripts through the command-execution tool. The server exposes only connection checks and mail-reading tools. After restarting Desktop to load it, multiple scheduled runs have successfully read the mailboxes without asking for temporary command-network approval.

So your advice helped restore the profile option, while the MCP integration is the path currently making the digest work. I haven’t tested whether selecting the profile also fixes direct command-network access, so I don’t want to claim that is verified yet. Thanks again for helping clarify the configuration issue!