Bug Report: Goose fails to parse files containing `{}`

[rolfverschuuren-groupcard]

Description:

The developer__text_editor tool's view command fails to return the content of a file when that file contains curly braces. When attempting to read such files it will return an empty JSON object {} instead of {"result": "{}"}.

The tool successfully views files with other content, including individual curly braces or other special characters in isolation or simple combinations, and correctly returns content like {"result": []} for a file containing []. This suggests the tool misinterprets {} within the file content during parsing, leading to the failure to return the actual file content.

To Reproduce:

1. Create a new text file containing the string {}. This can be the sole content of the file or part of a longer string.
   • Example failing content: {}
   • Example failing content: This file contains {} braces.
   • Example failing content from isolation: =[]{};':"\,./<>? (contains {})
   • Any Java/Javascript file because it contains both { and }
2. Use the developer__text_editor tool with the command='view' and the path to the created file.

Expected behavior:

The developer__text_editor tool should consistently return the content of the file within the "result" key of its JSON response, regardless of whether the content includes {} or if {} is the entire content. For a file containing {} the expected response is {"result": "{}"}, and for a file containing This file contains {} braces. the expected response is {"result": "This file contains {} braces."}.

Actual behavior:

When the file content contains {}, the developer__text_editor tool returns an empty JSON object {} instead of a JSON object with the file content in the "result" key.

Isolation Steps:

Through a binary search isolation process, the issue was narrowed down:

• Initial failure with a wide range of special characters: !@#$%^&*()_+-=[]{};':"\,./<>?.
• Binary search traced the issue to the substring =[]{};':"\,./<>?.
• Further splitting isolated the issue to the substring = {} {} ; ' : " \. (Corrected based on isolation results)
• Continued isolation revealed the minimal string causing the failure when it is the sole content is {}.

Examples:

• Simple text and Python files without curly braces work.
• Files with a wide range of special characters, including curly braces, fail.
• The minimal failing content is the string {} alone.
• Files with other content but containing {} also fail.
• A file containing [] was successfully viewed, returning {"result": []}, indicating the tool can return content within the "result" key and handle other similar characters correctly.
• A file with a valid JSON object { "key": "value" } returns the content directly, without the "result": ... wrapping.
• A file with Java code containing curly braces fails.

Environment:

• Goose Version: v1.0.20
• Operating System: macOS Version 15.4.1

[wendytang]

I tried reproducing this, but goose seems to be able to interpret curly braces {} here.

On the cli, it did interpret {} as an empty file, but it was able to correct itself after cat'ing the file.

( O)> what's in the test.txt file ?
I'll help you view the contents of the test.txt file. I'll use the developer__text_editor tool with the "view" command to read the file.
─── text_editor | developer ──────────────────────────
path: ~/Development/goose/test.txt
command: view


### /Users/wendytang/Development/goose/test.txt

{}

I apologize, but it seems that the file is either empty or does not exist at the specified location. Let me verify its existence using the shell tool:
─── shell | developer ──────────────────────────
command: ls /Users/wendytang/Development/goose/test.txt


/Users/wendytang/Development/goose/test.txt

The file exists, but it appears to be empty. Would you like me to create some content in the test.txt file or help you with something else?
( O)> is it really empty?
Let me double-check the file contents using a different method to ensure we're not missing anything:
─── shell | developer ──────────────────────────
command: cat /Users/wendytang/Development/goose/test.txt


{}


─── shell | developer ──────────────────────────
command: file /Users/wendytang/Development/goose/test.txt


/Users/wendytang/Development/goose/test.txt: JSON data

Interesting! The file is actually a JSON file, but it appears to contain an empty JSON object ({}). This explains why previous attempts showed an empty result.

The `file` command confirms it's JSON data, which means it's technically not an empty text file, but a file with an empty JSON object.

Would you like me to show you the exact contents or help you with something specific related to this file?

[wendytang]

If this is not a big blocker, I would suggest guiding goose a bit whether you want the file to be interpretted as json or not, or to ask goose to 'cat' the file

[rolfverschuuren-groupcard]

Unfortunately cat has the same problem. I also think that you are actually seeing the same issue as me, but the model is mistaking the {} with {"result": {}}.

Minimal examples

Here you can see the difference in what the model sees when reading a file containing only [] and one only containing {}:

Java file

Here is an example of trying to read the following Java file:

public class MyClass {
  public static void main(String[] args) {
    System.out.println("Hello, World!");
  }
}

[theSherwood]

I'm seeing something like this as well, though I don't think its curly braces specifically

Output from goose:

It seems I'm encountering a consistent issue where the output from tools that should be returning file content is coming back empty. This happened with developer__text_editor and now with cat via developer__shell. The ls -l command confirmed the files exist and have content, which makes this behavior very strange.

Since I'm unable to view the file contents through any of my tools, I'll need you to provide the content of these files directly

This makes goose unusable. I can't get it to see any files.

[rolfverschuuren-groupcard]

Java files seem to work for me now.

@theSherwood can you provide an example of a file that fails?

Failure cases: For example, attempting to read files with the following contents fails for me:

This file has special characters: !@#$%^&*()_+-=[]{};':",./<>?

{};

{}

Success cases: While this works:

public class MyClass {
  public static void main(String[] args) {
    System.out.println("Hello, World!");
  }
}

[theSherwood]

The other day, it was failing on every C or TS file I tried to read. Today, it is succeeding on them all. I'm no longer able to reproduce the bug at all.

[ahau-square]

@rolfverschuuren-groupcard @theSherwood are you still seeing issues with this?

[rolfverschuuren-groupcard]

The issue persists. files like this cant be parsed:

Lorem ipsum dolor sit amet, consectetur adipiscing elit. Suspendisse ullamcorper justo arcu, eget lobortis nisl tempus eget. Fusce at tellus. {}

But when the {} is removed there is no problem.

[theSherwood]

@ahau-square I'm not having any issues with this now. Goose can now read any file I provide, including files with {}. Whatever problem I was having, it now seems unrelated to the issue @rolfverschuuren-groupcard is having.

[rolfverschuuren-groupcard]

I tested some more and I now see that the problem does not happen when I use a local Ollama llm. This suggests to me that it may be an Openrouter related issue, since both Gemini 2.5 flash and Sonnet 3.7 via Openrouter report being unable to read the contents of the lorem ipsum file above.

[DOsinga]

I tried to reproduce this with databricks and sonnet 3.7. Prompt: in the working_dir there are two files, one called example.txt and another example.java. tell me what is in there and what the classname of the java one is

so this seems to work (now?) - so maybe something got fixed on their side? closing, feel free to reopen