[P0 enterprise] Literal glob chars in exact workspace paths break Computer Use; suggested /** fails

What version of Codex is running?

Verified current environment:

• Codex Desktop: 26.727.51351 (bundle 6119)
• Bundled CLI: codex-cli 0.146.0-alpha.9.2
• Standalone CLI: codex-cli 0.147.0-alpha.4
• macOS: 26.5.2 (25F84), Apple silicon

Severity / enterprise impact

This is a P0-level enterprise adoption blocker for organizations whose established shared-drive, repository, or project naming conventions include legal filesystem characters such as literal *, ?, [, or ].

Non-technical business teams commonly use visible punctuation to group or sort shared folders. Renaming an established folder is not a trivial workaround: paths can be embedded in automation, integrations, shortcuts, documentation, permissions, sync clients, memories, and human workflows. Requiring path changes can create broken references and fragmented sources of truth.

The defect can disable or destabilize core Codex value paths—including Codex Desktop/CLI workspace access, Computer Use, Browser/Node REPL and other nested/plugin runtimes—while causing repeated diagnosis attempts, duplicated artifacts, fragmented task/session continuity, and substantial token waste.

What issue are you seeing?

An existing exact workspace path containing a literal glob metacharacter is reinterpreted as a filesystem glob. Read/write permission compilation then rejects the path even though it is a valid literal filesystem path.

Sanitized synthetic example:

/Volumes/Enterprise Shared Drive/* Repositories/Business Operations

Representative error:

filesystem glob path `/Volumes/Enterprise Shared Drive/* Repositories/Business Operations` only supports `deny` access; use an exact path or trailing `/**` for `write` subtree access

Appending /** does not escape the earlier literal *. The current implementation strips only the terminal /**, then still detects the earlier literal metacharacter and rejects the entry.

The current source confirms this behavior:

• compile_read_write_glob_path removes only a trailing /**, then errors if glob characters remain.
• contains_glob_chars_for_platform classifies exactly *, ?, [, and ] as glob characters.
• remove_trailing_glob_suffix only calls strip_suffix("/**").

Source: https://github.com/openai/codex/blob/main/codex-rs/core/src/config/permissions.rs

What steps can reproduce the bug?

1. Create a real directory containing a literal asterisk:

``text
/tmp/* Repositories/example-project
``

1. Open that exact directory as a Codex Desktop workspace, or configure it as an exact workspace root with read/write access.
2. Start Computer Use or another nested runtime that recompiles/serializes the permission profile.
3. Observe the filesystem-glob error before the nested runtime can initialize or access the workspace.
4. Append /** to the permission entry.
5. Observe that the earlier literal * is still treated as a glob and the error persists.

Equivalent regression coverage should include literal ?, [, and ].

Control evidence

• The exact directory exists and is accessible through normal macOS filesystem operations.
• The same Computer Use/plugin runtime initializes successfully from a control workspace whose path contains none of *, ?, [, or ].
• A repository-scoped permission profile and a separate alias path without glob metacharacters can allow a fresh task to initialize Computer Use, proving that the plugin itself is healthy.
• That alias/profile procedure is only an operational workaround. Existing tasks retain stale permission state; configuration can diverge; path provenance becomes ambiguous; and the original workspace remains broken.

Why rename or symlink workarounds are insufficient

• Renaming the canonical folder can break established automation, links, sync rules, documentation, and integrations.
• A symlink that retains the special character retains the parser failure.
• Renaming the original and placing a special-character symlink at the old path does not repair clients that continue to authorize or serialize the old literal path.
• A second no-special-character alias can work in a newly configured task, but creates another path identity and increases the risk of configuration drift, wrong-checkout work, duplicated artifacts, and fragmented memories. It is not an upstream fix.

What is the expected behavior?

A permission entry explicitly supplied as an exact filesystem path must preserve exact-path identity even when the path contains characters that also have meaning in glob syntax.

Users should not have to:

• rename established enterprise folders;
• create alternate path identities;
• broaden access to a parent directory;
• disable sandboxing;
• recreate every affected task; or
• abandon Computer Use or nested/plugin runtimes.

Suggested fix / regression coverage

1. Preserve the tagged exact-path variant through permission-profile serialization and nested-runtime handoff; do not infer a glob from characters inside an exact path.
2. Alternatively, provide an explicit, documented literal-path/escaping syntax that is applied before glob classification.
3. Add macOS and Windows tests for exact read and write roots containing:

• literal *
• literal ?
• literal [ and ]

1. Verify the main sandbox plus Computer Use, Browser/Node REPL, and other nested/plugin runtimes.
2. Verify that legitimate deny-glob behavior remains unchanged.
3. Audit transport and quoting for other legal path punctuation—especially apostrophe, exclamation mark, spaces, and periods—even though those characters are not part of this exact contains_glob_chars_for_platform classifier.

Related issue

• #35748 covers literal square brackets on Windows preventing Node REPL startup. This report broadens the missing coverage to literal asterisks/question marks, macOS, read/write workspace roots, Computer Use, other nested/plugin runtimes, and enterprise path-stability consequences.

All paths above are synthetic and sanitized. No private filesystem names or contents are included.

Additional verified evidence: shell/TOML quoting does not repair the Codex path parser

A bounded validation against a real directory whose literal name contains both an asterisk and an apostrophe confirmed:

• A correctly double-quoted full absolute path resolves successfully through the shell.
• A correctly single-quoted path, with any embedded apostrophe properly escaped, resolves to the same filesystem object.
• Backticks are command substitution in POSIX shells; they execute their contents and are not a quoting mechanism.
• Markdown backticks only format text and have no effect on the path passed to Codex.

This proves that correct shell quoting can preserve the literal filename for ordinary filesystem commands. It does not repair this Codex defect. Shell quote delimiters are removed before the child process receives the argument, and TOML single/double quotes delimit a string rather than tagging it as an exact literal path. The Codex permission compiler therefore receives the same path string containing * and reclassifies it as glob syntax. A shell escape such as \* is likewise consumed before this classifier or still leaves the metacharacter visible to contains_glob_chars_for_platform.

Regression tests should explicitly pass the same exact path through:

1. a double-quoted CLI argument;
2. a correctly escaped single-quoted CLI argument;
3. TOML basic and literal strings;
4. Desktop workspace serialization; and
5. Computer Use / Browser / Node REPL permission-profile handoff.

All forms must retain exact-path identity rather than inferring a glob from the resulting string.

Downstream damage amplification

The failure is not limited to one startup error. Poor literal-path handling forces agents and users into alternate path identities and repeated recovery attempts, which can cascade across the Codex operating model:

• duplicate or divergent workspace/project registrations;
• extra clean-path task directories, worktrees, branches, checkouts, and temporary fixtures;
• artifacts written under an alias while other sessions continue using the canonical path;
• fragmented task histories, memories, indexes, caches, handoff documents, and provenance;
• stale permission snapshots in existing tasks after configuration changes;
• broken absolute references in scripts, automation, integrations, IDE registrations, sync rules, shortcuts, and documentation;
• wrong-checkout or wrong-path edits when multiple lexical paths point to the same repository;
• repeated failed Computer Use/plugin initialization, duplicated diagnosis, token waste, and lower-quality or fragmented agent output.

Renaming the canonical directory, replacing it with a special-character symlink, or adding a clean alias can relocate or multiply these identity problems. It does not provide the missing product guarantee: an exact path must remain exact across serialization, sandbox compilation, nested runtimes, worktrees, task history, and memory/provenance systems.

Related upstream reports found in the broader literal-path audit

Exact or likely same root

• #35748 — literal square-bracket read root is re-parsed as a glob and prevents nested Node REPL startup on Windows.
• #18466 — square-bracket directory paths break Desktop save/write behavior; the report does not isolate the permission compiler, so this is a likely related path class rather than a confirmed duplicate.

Adjacent literal-path failures (different parsers or surfaces)

• #18555 — @ inside CODEX_HOME is misread as a Git @ref, breaking bundled Computer Use.
• #25238 and #11102 — unquoted paths containing spaces break Windows launch/editor flows.
• #34075 and #25524 — whitespace is mishandled by patch/repository tooling.
• #34261 and #35780 — periods inside project paths are split by the -c configuration-key parser.
• #2458 and #2584 — shell-command construction mishandles bracket/parenthesis and dollar-sign paths.

These adjacent reports are not asserted to share this permission-compiler root cause. Together they show that exact literal-path identity is being lost at multiple Codex parsing and transport layers.