TUI trust prompt hides config/batchWrite failure cause when setting project trust

Root cause: the underlying app-server error is preserved in the eyre cause chain, but the TUI renders it with {error} (outermost context only), so the real reason is dropped.

In codex-rs/tui/src/onboarding/onboarding_screen.rs (around L607–L618 on 56958f2), the same handler logs the full chain with {error:?} but shows the user only the outermost context via {error}:

Err(error) => {
    tracing::error!(
        "failed to persist trusted project state for {}: {error:?}",   // full chain -> logs
        trust_target.display()
    );
    if let Step::TrustDirectory(widget) = ... {
        widget.error = Some(format!(
            "Failed to set trust for {}: {error}",                       // top-level only -> user
            trust_target.display()
        ));
    }

The cause chain is real: write_trusted_project → write_config_batch in tui/src/config_update.rs ends with .wrap_err("config/batchWrite failed in TUI") (color_eyre WrapErr), so the Report's source is the actual JSON-RPC/app-server error (read-only config, invalid config, transport failure, etc.). format!("...: {error}") uses eyre's Display, which prints only the outermost context — hence the user sees config/batchWrite failed in TUI with the source dropped, while the log line two statements above ({error:?}) has the real reason.

Suggested fix (outline): render the chain with eyre's alternate Display — change {error} at L615 to {error:#} (single line, joins the full cause chain with : ), or {error:?} for the verbose form. No new dependency; {:#}/{:?} on eyre reports is already used across the codebase (including the tracing::error! immediately above). That surfaces the underlying reason the report is asking for.

Happy to put up a PR if a maintainer wants it

we are also getthing this error when trying to change models or anything that is located inside the config toml.
Did you find any workaround @Pluviobyte @mahendra202602 ?

Initial change error:

<img width="1461" height="211" alt="Image" src="https://github.com/user-attachments/assets/2da90398-897d-4085-9182-5c2a32d0cd41" />

This is what codex found out:

<img width="1313" height="277" alt="Image" src="https://github.com/user-attachments/assets/6641f248-e66d-4cf2-8ba2-d3232f6c969b" />

At the end of the day OpenAI should really think about providing a safe way to bind certain files/folders inside docker containers.
We are not allowed to bind root .codex folders as we break all other states and features codex provides (app-agent/daemon, sockets, ...) and we are not allowed to bind explicit files, as codex needs full access on folder level to them as well.
We are left with no options.

We've decided to make all directories trusted by default unless you are using :read-only permissions. This makes the CLI (TUI) consistent with the desktop app's behavior. This will be included in the next release.

Is the fix out for this? I'm on 0.149.1 now and still having it. In previous versions I was able to bypass the permission prompt with ^C but now this just causes it to exit, so I can't use Codex at all.

After more discussion, we decided not to trust all directories by default. Reopening the issue.