openai / openai/codex

Remote ChatGPT desktop tasks ignore writable_roots for new tasks

Open
#39,996 1 comment 0 reactions 0 assignees View on GitHub

Nobody has claimed this yet.

app app-server bug remote sandbox
Dominant language
Rust
Stars
125k
Forks
19.4k
PR merge metrics
PR metrics pending

Description

What version of the Codex App are you using (From “About Codex” dialog)?

26.819.11345

What subscription do you have?

enterprise

What platform is your computer?

Darwin 25.5.0 arm64 arm

What issue are you seeing?

Title: Remote ChatGPT desktop tasks ignore writable_roots for new tasks

Environment

  • ChatGPT/Codex desktop app on macOS connecting by SSH to a Linux host
  • Remote server: Codex app-server / code-mode host
  • Codex release: 0.147.0
  • A network filesystem mount is rw for the authenticated user over SSH

Config on the remote host (~/.codex/config.toml)

sandbox_mode = "workspace-write"

[sandbox_workspace_write]
writable_roots = [
"/path/to/runtime/database-directory",
]

Expected
Every newly created remote Codex task should receive rw access to the configured
additional writable root.

Actual
New ChatGPT desktop tasks run Bubblewrap with:
--ro-bind / /
--bind /path/to/runtime/database-directory
/path/to/runtime/database-directory

but inside those new tasks:
test -w /path/to/runtime/database-directory # false
test -w /path/to/runtime/database-file.sqlite3 # false
findmnt -T /path/to/runtime/database-directory # ro

The directory and database file are owned by the authenticated user and have
normal owner-write permissions. The same paths are writable over a normal SSH
session.

Restarting the remote app-server can make existing sessions see the directory
as rw, but newly created ChatGPT desktop tasks still receive it as ro.

What steps can reproduce the bug?

Expected
Every newly created remote Codex task should receive rw access to the configured
additional writable root.

Actual
New ChatGPT desktop tasks run Bubblewrap with:
--ro-bind / /
--bind /path/to/runtime/database-directory
/path/to/runtime/database-directory

but inside those new tasks:
test -w /path/to/runtime/database-directory # false
test -w /path/to/runtime/database-file.sqlite3 # false
findmnt -T /path/to/runtime/database-directory # ro

The directory and database file are owned by the authenticated user and have
normal owner-write permissions. The same paths are writable over a normal SSH
session.

Restarting the remote app-server can make existing sessions see the directory
as rw, but newly created ChatGPT desktop tasks still receive it as ro.

What is the expected behavior?

Expected
Every newly created remote Codex task should receive rw access to the configured
additional writable root.

Additional information

No response

Contributor guide

Open the contributing guide

First steps

  1. Read the whole issue, then the project's contributing guide.
  2. Comment on the issue to say you are picking it up — it saves two people doing the same work.
  3. Fork the repository and make your change on a branch.
  4. Open a pull request that references the issue number.

Research direction

Start by tracing how the remote host reads ~/.codex/config.toml and constructs the Bubblewrap invocation for newly created tasks. Compare that path with existing sessions and verify completion by confirming that writable_roots is mounted rw, including the directory and database file, in every new task.

Written by the indexing model from the issue text.

Assessment

Tech stack
rust
Domain
backend, security
Issue type
Bug
Difficulty
4/5
Estimated time
3-5 days
Activity status
Active
Clarity
Mostly clear
Newbie friendliness
55/100

Get new issues in your inbox

A short digest of beginner-friendly GitHub issues.