Long output to stdout is cut to 50kB and tail is lost (model not notified about temporary file). #7846
Description
Issue with temporary file naming on Windows
- Model uses a tool which produces long (170kB) output to stdout.
- Goose limits output to first 50kB. Full output is written to temporary file.
- Goose notifies model that output is truncated and instructs to use head/tail/sed to access file.
- Goose prints wrong file name (but in logs I see correct file name)
- Model ignores this (I explain reasons below).
- Model has no knowledge about temporary file at all (I asked it later)
Wrong file name
Actual file name
Model has no knowledge about temporary file
As I discovered, this happens because Goose just cuts first 50kB of file and inserts note about temporary file existence at end of text. But tool output structured JSON data and model parse it appropriately: it ignores note about temporary file existence, because it thinks, that this notice is a part of data!
To Reproduce
Steps to reproduce the behavior:
- Force model to use tool producing large output of structured data (JSON for example)
- Check that the model fully reads the output
Expected behavior
Model should read full output from temporary file.
Ignoring tail of large output can cause incorrect results in practical scenarios.
Possible fix: separate notion of tool output to stdout and stderr. Add a notice not to stdout, but to stderr.
Please provide the following information
- OS & Arch: Windows 11 (Microsoft Windows [Version 10.0.26200.7840])
- Interface: GUI
- Version: 1.27.2
- Extensions enabled: summon, developer
- Provider & Model: custom_deepinfra – zai-org/GLM-4.7
Additional context
Please see logs:
diagnostics_20260312_11.zip
Model mention about temporary file:
So output was very large and was written into temporary file, right? Do you know this file name?
The user is asking about temporary files. Let me look back at the function description for shell:
"Returns an object with stdout and stderr as separate fields. The output of each stream is limited to up to 2000 lines, and longer outputs will be saved to a temporary file."
So yes, when output exceeds 2000 lines, it gets saved to a temporary file. However, the function doesn't return the filename - it just returns the content in stdout/stderr fields.
The cached results I have show url, text, title, and time - there's no mention of temporary file names for the web-search -fetch results.
I should be honest: I don't have access to the temporary file name because the web-search function returns the text content directly in the JSON response, not a file path. The shell command outputs might have temporary files, but for web-search -fetch, the text is contained within the response object.
Let me check the shell function description again to see if there's any way to access temp file names or if they're mentioned.
Looking at the shell function: "Returns an object with stdout and stderr as separate fields. The output of each stream is limited to up to 2000 lines, and longer outputs will be saved to a temporary file."
But the response format only shows stdout, stderr, and returncode - no file path information.
So I need to tell the user that:
Yes, large outputs can be written to temporary files
But for the web-search -fetch commands I used, the content was returned directly in the response (in the text field)
I don't have access to the actual temporary file names
If they used shell commands that generated large output, the temp files would be in a system temp directory