Codex Desktop file tree hides project dot-directories such as .codex while search can find them

What version of the Codex App are you using?

Codex Desktop 26.527.31326 (CFBundleVersion 3390)

CLI: codex-cli 0.135.0-alpha.1

What platform is your computer?

macOS 26.5 (25F71), arm64

What issue are you seeing?

In Codex Desktop, the project file tree appears to hide top-level dot-directories even when those directories are important Codex/project configuration folders.

For example, a local project contains tracked top-level directories/files such as:

• .codex/
• .docs/
• .harness/
• .github/
• .cursor/
• .gitignore

The file tree does not show many of these entries, so it looks like the project is missing a large part of its files. However, Codex search can still find files inside those directories, and the agent/terminal can read them normally. This creates a confusing mismatch between the file browser and the actual local workspace.

This is especially confusing because .codex/ is a first-class Codex project folder. In this project, .codex/state/lifecycle.yaml and related files are part of the local workflow state, but the Desktop file tree does not make them discoverable.

Steps to reproduce

1. Open a local project in Codex Desktop.
2. Ensure the project has top-level dot-directories, for example .codex/, .docs/, .harness/, .github/.
3. Open the Codex Desktop file tree.
4. Observe that these dot-directories are missing or not fully discoverable.
5. Use search for a file inside one of those directories, such as .codex/state/lifecycle.yaml or .docs/INDEX.md.
6. Observe that search can find the file even though the file tree did not show the parent directory.

Expected behavior

Codex Desktop should either:

• show hidden/dot directories by default when they are part of the project workspace, especially .codex/, or
• provide a visible Show hidden files / Show dotfiles toggle in the file tree, or
• at minimum whitelist Codex-relevant project directories such as .codex/.

The file tree, search, and agent filesystem access should not give conflicting impressions about what exists in the workspace.

Workaround verified locally

Creating non-dot symlink aliases makes the same content visible in the Codex file tree, for example:

ln -sfn .codex __codex
ln -sfn .docs __docs
ln -sfn .harness __harness

After adding those local-only aliases and excluding them from git, Codex Desktop can display the aliased paths. This suggests the underlying files are accessible and the issue is likely the file tree's dot-directory filtering/display logic, not filesystem access or indexing.

Why this matters

Codex projects often rely on .codex/ for local configuration/state. Hiding it in the Desktop file tree makes the app feel inconsistent: the agent can use the folder, search can find it, but the user cannot browse it. This is particularly surprising for users migrating from IDE plugins to the Codex Desktop app.