Tool Invocation by LLM return empty results

[dchao34]

What version of Codex is running?

0.31.0

Which model were you using?

gpt-5

What platform is your computer?

Linux 6.11.0-1013-gcp x86_64 x86_64

What steps can reproduce the bug?

From my cloned github respository root, I open codex on the terminal.

Then I prompt to list the directory contents and I get:

▌Can you list the contents of the present directory?

Listing files in the current workspace directory.

• Explored
└ List ls -la

• Ran pwd && ls -la

The current directory /home/dschao/wlt appears to be empty. No files or folders found. Do you
want me to initialize a project here or pull an existing repo?

I am remote ssh'd into a GCP VM.

Also attaching logs with export RUST_LOG="warn,codex_core=trace,codex_tui=trace".

codex-tui.log

What is the expected behavior?

It should be able to list my directory - there are many files and directories...

What do you see instead?

It seems to think ls -la returns empty.

Additional information

I am ssh'd into a GCP VM.

On my Mac it all works.

Claude Code works on the same VM.

[mwcrutcher]

Sorry to just pop in, but I'm diagnosing some problems and I wandered into your output thinking it might be related (it's not) but I think the problem you're seeing is something I've seen before (related to mount points on a WSL 2 distro). Look at this message: "�[2m2025-09-09T22:26:53.488619Z�[". Where you're asking ls to be run is outside of your workspace.

It looks to me like Codex is executing ls (returns exit code 0) but because it's outside of the workspace it "redacts" it. I'll leave it to an expert, I just took a very quick look (trying to help but I could be wrong). I think what's going on should be clearer (it should definitely and quickly fail), but I don't think that what you requested "should work".

[dchao34]

I imagine it is something to do with not being in the workspace... but I feel that my use of it suggest that I ought to be there:

• I cloned my git repository.
• I cd into it.
• I run codex there.
• When I do @some-file from the chat box, it actually does find my file to autocomplete it. It's only when the LLM invokes ls that the output is perhaps redacted.
• /status also shows that the workspace is where it is cloned to.

Let me know if I can try some other commands that could be helpful to you.

[mwcrutcher]

Apologies if I lead you astray, I'm just a random guy that looked at this, hopefully being helpful. I sent you the wrong timestamp based on a find error, apologies. The actual timestamp I saw that made me say "that looks weird" is: 2m2025-09-09T22:27:05.937970Z

There is a lot going on there that I don't understand, but things I saw that made me say "weird":

• CWD is /home/dschao/wlt, but WORKSPACE is /mnt/users/dschao/workspace.
• Codex is running the shell under RedirectForShellTool with WorkspaceWrite { writable_roots: [], ... }, I think that effectively means "no writable roots"
• PATH starts with a temp dir (/tmp/.tmpLY1FPY) that I think is for Codex shims (for things like LS)

I'm not an expert but I'd:

• Start Codex where you work: codex -C /home/dschao/wlt
• Maybe very temporarily turn on "danger-full-access" with codex --sandbox danger-full-access just to see if "running unsandboxed" changes your output, my guess is that this will work and will prove that ls output is being obfuscated because of sandbox policy
• modify ~/.codex/config.toml add "writable-roots": https://github.com/openai/codex/blob/main/docs/config.md#sandbox_mode (find the comment: "# Optional list of additional writable roots beyond $TMPDIR and /tmp.")
• try to simplify, there are multiple layers of redirection, I think

I think there are bugs represented in the logs (2 prompts generating 1MB of logging with the full system prompt repeated dozens of times seems "suboptimal"), but I think that your root issue is related to sandbox policy and "path misdirection".

[dchao34]

No problem at all! Thanks so much for your insights @mwcrutcher :)

codex --sandbox danger-full-access

also didn't work. I'll just have to dig around some more... or maybe someone here will beat me to it.

[minhluuquang]

For anyone running into this problem, here is my case

The Codex cli always runs commands by calling:

bash -lc "your command"

(for example, bash -lc "ls -la" or bash -lc "pwd").

If you’re using fish (or any shell other than bash) as your main shell, this can break if your ~/.bash_profile or ~/.bashrc forces bash to immediately exec into another shell. In my case, my ~/.bash_profile looked like this:

export PATH="${PATH}:${HOME}/.local/bin"
export SHELL=/bin/zsh
exec /bin/zsh -l

Because of the exec /bin/zsh -l, bash never actually ran the command — it just switched over to zsh and stopped, causing empty output for codex cli

Fix:
Check your ~/.bash_profile or ~/.bashrc for any lines like exec /bin/zsh -l (or exec fish -l) and remove them. After I removed that line, Codex worked perfectly again, even though my main shell is still fish.

[dchao34]

Billiant @minhluuquang - great observation on the bash -lc!

Indeed, that was my problem too.

In my case, I still had to do the exec /bin/zsh -l for other reasons... so I ended up doing a hacky thing (thank you GPT for this hint too):

if shopt -q login_shell; then
  if [[ $- == *i* && -z ${BASH_EXECUTION_STRING:-} ]]; then
    exec "$(command -v zsh)" -l
  fi
fi

Basically... only when we are in a login shell, in interactive mode, and not executing under bash -c do we run exec. This covers my ssh login case, but let codex use bash -c.