[BUG] write_to_file breaks processing with unescaped JSON contents

[rkfg]

Problem (one or two sentences)

JSON contents seem to be not escaped properly in tool requests but it's just my guess. Other files like go.mod can be created properly.

Context (who is affected and when)

Roo gets stuck whenever a JSON-like files need to be created. Happens with JS/TS projects during creation of package.json or tsconfig.json. Can be worked around with executing a command like echo 'file contents' > package.json but it's clearly a hack. I'm running a local GLM 4.7 using llama.cpp with 202k context on a single 5090 RTX, Debian testing.

Reproduction steps

1. Prompt to "Create a sample package.json file"
2. After some thinking nothing happens, no further API requests happen.

Expected result

package.json is created

Actual result

Roo stops doing anything

Variations tried (optional)

Prompt to "Create a sample go.mod file" and it works as expected.

App Version

3.45.0

API Provider (optional)

OpenAI Compatible

Model Used (optional)

GLM 4.7 Flash Q4

Roo Code Task Links (optional)

No response

Relevant logs or errors (optional)

{
    "role": "assistant",
    "content": [
      {
        "type": "reasoning",
        "text": "The user wants me to create a sample package.json file. This is a straightforward task - I need to create a package.json file in the current workspace directory. Since this is a simple task with just one step, I don't need to create a todo list.\n\nI'll create a basic but comprehensive package.json file that includes common fields like:\n- name\n- version\n- description\n- main (entry point)\n- scripts (common npm scripts)\n- dependencies\n- devDependencies\n- keywords\n- author\n- license\n\nLet me create this file.",
        "summary": []
      },
      {
        "type": "text",
        "text": "I'll create a sample package.json file with common fields for a Node.js project."
      },
      {
        "type": "tool_use",
        "id": "YowtMyvADBhHNfJkss2putQcEI6qidlx",
        "name": "write_to_file",
        "input": {
          "path": "package.json",
          "content": {
            "name": "sample-project",
            "version": "1.0.0",
            "description": "A sample Node.js project",
            "main": "index.js",
            "type": "module",
            "scripts": {
              "start": "node index.js",
              "dev": "node --watch index.js",
              "test": "echo \"Error: no test specified\" && exit 1",
              "lint": "eslint .",
              "format": "prettier --write ."
            },
            "keywords": [
              "sample",
              "nodejs",
              "javascript"
            ],
            "author": "Your Name <your.email@example.com>",
            "license": "MIT",
            "repository": {
              "type": "git",
              "url": "https://github.com/yourusername/sample-project.git"
            },
            "bugs": {
              "url": "https://github.com/yourusername/sample-project/issues"
            },
            "homepage": "https://github.com/yourusername/sample-project#readme",
            "engines": {
              "node": ">=18.0.0",
              "npm": ">=9.0.0"
            },
            "files": [
              "dist",
              "src",
              "README.md",
              "LICENSE"
            ],
            "dependencies": {
              "express": "^4.18.2"
            },
            "devDependencies": {
              "eslint": "^8.50.0",
              "prettier": "^3.0.3"
            }
          }
        }
      }
    ],
    "ts": 1769589325760
  }

The input/content value is suspicious because it's passed with no escaping as is. For example, when creating a pom.xml file the entire content is quoted:

{
    "role": "assistant",
    "content": [
      {
        "type": "reasoning",
        "text": "The user wants me to create a sample pom.xml file. This is a Maven project configuration file for Java projects. Since the workspace is empty, I'll create a basic but complete pom.xml file that can serve as a template for a Maven project.\n\nLet me create a standard Maven pom.xml with common configurations.",
        "summary": []
      },
      {
        "type": "text",
        "text": "I'll create a sample pom.xml file for a Maven project. This will be a basic but complete template with common configurations."
      },
      {
        "type": "tool_use",
        "id": "q7gAnsrcatu4752yXMIay6OHnt8z1pJ5",
        "name": "write_to_file",
        "input": {
          "path": "pom.xml",
          "content": "<?xml version=\"1.0\" encoding=\"UTF-8\"?>\n<project xmlns=\"http://maven.apache.org/POM/4.0.0\"\n         xmlns:xsi=\"http://www.w3.org/2001/XMLSchema-instance\"\n         xsi:schemaLocation=\"http://maven.apache.org/POM/4.0.0\n         http://maven.apache.org/xsd/maven-4.0.0.xsd\">\n    <modelVersion>4.0.0</modelVersion>\n\n    <groupId>com.example</groupId>\n    <artifactId>my-project</artifactId>\n    <version>1.0.0</version>\n    <packaging>jar</packaging>\n\n    <name>My Project</name>\n    <description>A sample Maven project</description>\n\n    <properties>\n        <project.build.sourceEncoding>UTF-8</project.build.sourceEncoding>\n        <maven.compiler.source>11</maven.compiler.source>\n        <maven.compiler.target>11</maven.compiler.target>\n        <junit.version>5.10.0</junit.version>\n    </properties>\n\n    <dependencies>\n        <!-- JUnit 5 for testing -->\n        <dependency>\n            <groupId>org.junit.jupiter</groupId>\n            <artifactId>junit-jupiter-api</artifactId>\n            <version>${junit.version}</version>\n            <scope>test</scope>\n        </dependency>\n        <dependency>\n            <groupId>org.junit.jupiter</groupId>\n            <artifactId>junit-jupiter-engine</artifactId>\n            <version>${junit.version}</version>\n            <scope>test</scope>\n        </dependency>\n    </dependencies>\n\n    <build>\n        <plugins>\n            <!-- Maven Compiler Plugin -->\n            <plugin>\n                <groupId>org.apache.maven.plugins</groupId>\n                <artifactId>maven-compiler-plugin</artifactId>\n                <version>3.11.0</version>\n                <configuration>\n                    <source>${maven.compiler.source}</source>\n                    <target>${maven.compiler.target}</target>\n                </configuration>\n            </plugin>\n\n            <!-- Maven Surefire Plugin for running tests -->\n            <plugin>\n                <groupId>org.apache.maven.plugins</groupId>\n                <artifactId>maven-surefire-plugin</artifactId>\n                <version>3.1.2</version>\n            </plugin>\n\n            <!-- Maven JAR Plugin -->\n            <plugin>\n                <groupId>org.apache.maven.plugins</groupId>\n                <artifactId>maven-jar-plugin</artifactId>\n                <version>3.3.0</version>\n                <configuration>\n                    <archive>\n                        <manifest>\n                            <mainClass>com.example.Main</mainClass>\n                        </manifest>\n                    </archive>\n                </configuration>\n            </plugin>\n        </plugins>\n    </build>\n</project>\n"
        }
      }
    ],
    "ts": 1769589517826
  }

[roomote]

I've analyzed this issue and here's my proposed implementation plan:

Root Cause

When certain models (like GLM 4.7 via OpenAI Compatible API) output a write_to_file tool call for JSON content, they incorrectly pass the content parameter as a JSON object instead of a string. For example:

"input": {
  "path": "package.json",
  "content": { "name": "sample-project", ... }  // Should be a string!
}

The tool schema explicitly defines content as type: "string", but some models do not follow this schema properly.

Proposed Fix

Add defensive type coercion in src/core/assistant-message/NativeToolCallParser.ts to handle cases where content is not a string:

1. In parseToolCall method (lines 804-811): Add a check that converts non-string content to a string using JSON.stringify():

   case "write_to_file":
     if (args.path !== undefined && args.content !== undefined) {
       nativeArgs = {
         path: args.path,
         content: typeof args.content === "string" ? args.content : JSON.stringify(args.content, null, 2),
       } as NativeArgsFor<TName>
     }
     break

2. In createPartialToolUse method (lines 403-410): Apply the same type coercion for partial streaming updates.

This is a defensive fix that gracefully handles model misbehavior without changing the expected interface, similar to how the parser already handles type coercion for booleans (via coerceOptionalBoolean) and already stringifies non-string values for params (line 374).

Benefits

• Non-breaking change - models that correctly output strings are unaffected
• Enables compatibility with models that incorrectly output JSON objects for file content
• Follows the existing pattern in the codebase for handling model inconsistencies
• Includes appropriate formatting (JSON.stringify(content, null, 2)) for readability when objects are converted

Please mention @roomote in a comment saying that you approve this plan, and I'll proceed with the implementation.

[rkfg]

@roomote that's good, also would be great to handle errors explicitly so that the user isn't left in the dark.

[roomote]

Thanks @rkfg! I have seen your comment and will proceed with the implementation. I will add explicit error handling to ensure users get clear feedback when the content type coercion happens, so they are not left in the dark. I will open a PR shortly to share my progress.

[roomote]

Opened #11041 with my attempt at addressing this. The fix includes:

1. Type coercion: When content is not a string, it gets converted to a formatted JSON string using JSON.stringify(value, null, 2)

2. Explicit error handling: A warning is logged when coercion happens, so users can see in the console that the model sent non-string content:

   [NativeToolCallParser] Model sent non-string content for 'write_to_file' tool. 
   Expected string, received object. Converting to JSON string. 
   This may indicate the model is not following the tool schema correctly.
   

3. Test coverage: Added comprehensive tests for string, object, array, and number content types

Feedback welcome!