# Agent terminal: no stdout in tool result and read\_file can't see files that terminal created

**URL:** <https://forum.cursor.com/t/agent-terminal-no-stdout-in-tool-result-and-read-file-cant-see-files-that-terminal-created/153332>\
**Category:** Bug Reports\
**Tags:** sandbox, terminal\
**Created:** [March 2, 2026, 12:12am UTC](https://forum.cursor.com/t/agent-terminal-no-stdout-in-tool-result-and-read-file-cant-see-files-that-terminal-created/153332 "2026-03-02T00:12:15Z")\
**Posts on this page:** 4\
**Page:** 1

<div class="post-metadata">

**Author:** ![Art\_Botterell](https://avatars.discourse-cdn.com/v4/letter/a/c57346/32.png) [@Art\_Botterell](https://forum.cursor.com/u/Art_Botterell)\
**Post date:** [March 2, 2026, 12:12am UTC](https://forum.cursor.com/t/agent-terminal-no-stdout-in-tool-result-and-read-file-cant-see-files-that-terminal-created/153332/1 "2026-03-02T00:12:16Z")

</div>

### Where does the bug appear (feature/product)?

Cursor IDE

### Describe the Bug

Two related behaviors prevent the agent from verifying the results of terminal commands:

1. Command output not returned: When the agent runs a terminal command (e.g. git status, git log -1, cat file), the command executes and returns an exit code (e.g. 0), but the stdout/stderr output is not included in the tool result shown to the agent. The agent receives something like “Command output: (empty)” or no output at all. So the agent cannot use command output to verify success or make decisions.

2. Files created by terminal not visible to read\_file: When the agent runs a command that writes to a file in the workspace (e.g. git log -1 --oneline \> scripts/result.txt or echo test \> scripts/diagnostic.txt), the command completes successfully (exit 0). When the agent then uses the read\_file tool on that same path (e.g. scripts/result.txt), the tool returns “File not found.” So the agent cannot work around missing stdout by redirecting to a file and reading it. The Cursor docs (Terminal / Sandbox) state that the sandbox has “Read and write access to workspace directories”; the agent can read existing workspace files with read\_file, but cannot read files that were just created by a terminal command in the same workspace.

Together, this means the agent has no reliable way to observe the outcome of terminal commands in the same session - neither via stdout nor via reading a file it wrote.

### Steps to Reproduce

teps to reproduce

1. In Composer/Agent, ask the agent to run a simple command that produces output, e.g. cd \<workspace\_root\> && git log -1 --oneline.
2. Observe: the command runs (exit code 0), but the agent’s tool result does not contain the git output.
3. Then ask the agent to run a command that writes to a file in the workspace, e.g. cd \<workspace\_root\> && echo “hello” \> scripts/test-output.txt.
4. Ask the agent to read that file (e.g. read\_file on scripts/test-output.txt or the full path).
5. Observe: read\_file returns “File not found” even though the write command succeeded and the path is inside the workspace.

### Expected Behavior

- Command output: The run\_terminal\_cmd (or equivalent) tool result should include the full stdout and stderr of the command so the agent can verify results and respond appropriately.
- Files created by terminal: Files created by the agent’s terminal commands in the workspace should be visible to the agent’s read\_file tool (same workspace, same path). Per the docs, the sandbox has read/write access to workspace directories, so writes from the terminal and reads from read\_file should see the same workspace filesystem.

### Operating System

MacOS

### Version Information

Version: 2.5.26  
VSCode Version: 1.105.1  
Commit: 7d96c2a03bb088ad367615e9da1a3fe20fbbc6a0  
Date: 2026-02-26T04:57:56.825Z  
Build Type: Stable  
Release Track: Default  
Electron: 39.4.0  
Chromium: 142.0.7444.265  
Node.js: 22.22.0  
V8: 14.2.231.22-electron.0  
OS: Darwin arm64 25.3.0

### For AI issues: which model did you use?

As selected in Composer for the current conversation. Settings has multiple models enabled: Composer 1.5, GPT-5.3 Codex, Sonnet 4.6, and Opus 4.6. Unable to see which one is active in this chat.

### Does this stop you from using Cursor

No - Cursor works, but with this issue

---

<div class="post-metadata">

**Author:** ![Art\_Botterell](https://avatars.discourse-cdn.com/v4/letter/a/c57346/32.png) [@Art\_Botterell](https://forum.cursor.com/u/Art_Botterell)\
**Post date:** [March 2, 2026, 12:52am UTC](https://forum.cursor.com/t/agent-terminal-no-stdout-in-tool-result-and-read-file-cant-see-files-that-terminal-created/153332/3 "2026-03-02T00:52:55Z")

</div>

Um… never mind? My model thought we were being constrained by Cursor, but it turns out the problem was that Cursor had simply not updated it’s working path and was trying to operate in a folder that did not exist anymore. Sorry for the wasted bandwidth.

---

<div class="post-metadata">

**Author:** ![deanrie](https://sea3.discourse-cdn.com/cursor1/user_avatar/forum.cursor.com/deanrie/32/1263_2.png) [@deanrie](https://forum.cursor.com/u/deanrie)\
**Post date:** [March 2, 2026, 5:29am UTC](https://forum.cursor.com/t/agent-terminal-no-stdout-in-tool-result-and-read-file-cant-see-files-that-terminal-created/153332/5 "2026-03-02T05:29:46Z")

</div>

Hey, glad you figured it out! An outdated working path that points to a folder that doesn’t exist would explain both issues, empty terminal output and `read_file` returning “file not found”.

If you’re seeing something similar, make sure your workspace is opened from the correct folder that actually exists. If you moved or renamed the project folder, reopen it in Cursor from the new location.

Closing this out.

---

<div class="post-metadata">

**Author:** ![system](https://sea3.discourse-cdn.com/cursor1/user_avatar/forum.cursor.com/system/32/99069_2.png) [@system](https://forum.cursor.com/u/system)\
**Post date:** [March 24, 2026, 5:30am UTC](https://forum.cursor.com/t/agent-terminal-no-stdout-in-tool-result-and-read-file-cant-see-files-that-terminal-created/153332/6 "2026-03-24T05:30:32Z")

</div>

This topic was automatically closed 22 days after the last reply. New replies are no longer allowed.
