Allow configuring Codex app artifact/output directory instead of defaulting to ~/Documents/Codex

Open 💬 2 comments Opened Jun 18, 2026 by Ethan-void
💡 Likely answer: A maintainer (github-actions[bot], contributor) responded on this thread — see the highlighted reply below.

What variant of Codex are you using?

Codex desktop app, macOS

What feature would you like to see?

Feature request: allow users to configure the default Codex artifact/work/output directory.

Current behavior:
On macOS Codex app, when using non-project chats, file-import chats, or artifact-generating tasks, Codex creates visible working/output folders under:

~/Documents/Codex

Examples include folders such as:

  • new-chat
  • files-mentioned-by-the-user-...
  • applications-mentioned-by-the-user-...
  • zotero-pdf
  • plugin-computer-use-...

These folders can contain work/ and outputs/ subdirectories with generated intermediate files and final artifacts.

Problem:
On many Macs, the Documents folder is synced by iCloud Drive. This means Codex-generated files under ~/Documents/Codex may be uploaded to iCloud automatically.

This can be risky because:

  • intermediate files can become very large, especially for PDF, video, image, spreadsheet, or data-processing tasks;
  • generated files are often temporary and not worth syncing;
  • artifacts may contain sensitive personal, academic, or project context;
  • users may not realize these files are being synced through iCloud;
  • there is currently no obvious setting to move this default folder to a local non-iCloud path.

Clarification:
This is especially relevant for chats that are not attached to a normal local project directory, or tasks involving uploaded files / generated artifacts. For regular code projects opened under a local repo, Codex can work inside the project or worktree, but non-project artifact workflows currently appear to use ~/Documents/Codex.

Suggested improvements:

  1. Add a setting in Codex app to configure the default artifact/work/output directory.
  2. Allow users to choose a local non-iCloud path, such as:

~/.codex/artifacts
~/AppData/Codex
~/Dev/Codex-Artifacts

  1. Warn users if the selected path is inside iCloud-synced Documents/Desktop.
  2. Provide a storage management panel to view, clean up, or auto-delete old work/output folders.
  3. Optionally separate:
  • session transcripts
  • temporary work files
  • final user-facing outputs

so users can decide what should be retained or synced.

Why this matters:
For users with iCloud Drive enabled for Documents, the current default can unexpectedly sync large or sensitive Codex-generated files. A configurable local artifact directory would make Codex safer and more predictable for local workflows.

Platform:
macOS Codex app.

Additional information

_No response_

View original on GitHub ↗

2 Comments

github-actions[bot] contributor · 2 months ago

Potential duplicates detected. Please review them and close your issue if it is a duplicate.

  • #27221

Powered by Codex Action

Thorncrag · 1 month ago

iCloud synchronization corrupted an active Git automation workspace

The ARRP automation checkout was located under macOS’s iCloud-synchronized Documents directory. While the automation was operating on that repository, CloudDocs reconciled remote filesystem changes into the live workspace.

This produced two serious forms of interference:

  • Active generated files disappeared. macOS logs showed CloudDocs applying 87 cloud-originated deletions during the exact interval when a newly generated 41-file Console data directory vanished.
  • Finder-style conflict copies appeared throughout the repository, including inside .git. Examples included duplicate Git indexes and a main 2 reference. These artifacts made the working tree dirty, broke repository validation, and caused Git operations to fail with an invalid-reference error.

Some duplicate files reappeared after being moved aside, confirming that an external synchronization process was continuing to modify the repository.

The logs established that macOS File Provider/CloudDocs applied the destructive reconciliation. They did not reveal whether the cloud-side changes originated from another Mac, an application, or stale iCloud state.

The underlying design problem was therefore using a cloud-synchronized folder as the authoritative working directory for an active Git repository and unattended automation. The repair was to preserve the affected checkout as evidence, move the operational checkout outside every File Provider–managed directory, and add a fail-closed check that prevents the automation from running when its directory—or any parent directory—is managed by File Provider.