bug(edit): edit tool crashes with 'undefined is not an object (evaluating output.args.filePath)' on existing file modification

[SuyeshBadge]

Bug Description

The edit tool crashes immediately when modifying existing files (oldString !== "") with:

undefined is not an object (evaluating 'output.args.filePath')

Steps to Reproduce

1. Have OpenCode call the edit tool with a non-empty oldString (e.g., changing a line in nuxt.config.ts)
2. The tool fails instantly (~6ms) with the TypeError above
3. Reproducible across different files and edit patterns
4. New file creation (oldString === "") works fine

Expected Behavior

The edit tool should find oldString, replace with newString, and write the file successfully.

Environment

• OpenCode version: 1.14.25
• OS: GNU/Linux Arch Linux
• Terminal: kitty

Logs

tool: "edit"
callID: "call_00_MvWilnmtVEEDIAXjoRydlm6K"
state:
  status: "error"
  input:
    filePath: "/home/.../nuxt.config.ts"
    oldString: "      apiBase: 'http://localhost:3001',"
    newString: "      apiBase: '/api',"
  error: "undefined is not an object (evaluating 'output.args.filePath')"
  time:
    start: 1777223543093
    end: 1777223543099

Same error replicated 3 times with different files (nuxt.config.ts, docker-compose.staging.yml, docker-compose.prod.yml).

RCA

The edit tool's execute returns { title, metadata, output } for the modified-file path. The AI SDK's toModelOutput/convertToModelMessages pipeline then tries output.args.filePath where output.args is undefined — the tool result doesn't have a .args property.

New file creation (oldString === "") works because that path has a different return flow. The bug is in the tool output processing layer where the result shape is assumed to have .args.filePath.

[PratikRai0101]

Hi! I'm taking a look at this. I'll trace the edit tool's return paths and ensure the payload includes the required args object for existing file modifications. Will open a Draft PR shortly.

[SuyeshBadge]

@rekram1-node @PratikRai0101 Could you please confirm whether this bug is valid? If so, by when are we planning to include the fix in the release? This is resulting in multiple LLM calls and unnecessary token leakage.

[rekram1-node]

I think the llm jjust called the tool incorrectly, maybe send a screenshot?

[SuyeshBadge]

@rekram1-node Please check the screenshot.

[PratikRai0101]

hey @SuyeshBadge @rekram1-node looking at the screenshot, this doesn't seem like a LLM calling issue. The tool inputs are perfectly valid. If the LLM had malformed the input, the input validation would have caught it before execution. Instead, the undefined is not an object (evaluating 'output.args.filePath') error happens after execution in the response mapping layer because the tool's return object is missing the args property entirely.

Root cause: The edit and write tools return { title, metadata, output } but the downstream AI SDK pipeline (convertToModelMessages → toModelOutput) accesses output.args.filePath, which is undefined because args is missing from the return object.

Evidence from the logs:

input.filePath is present and valid (the tool receives correct args).

The error occurs at ~6ms (tool execution is instant, crash is in post-processing).

Both edit and write tools fail with the identical error (see screenshot).

Fix: Include the original params as args in the tool return object:

TypeScript
return {
metadata: { ... },
title: ...,
output,
args: params, // missing which is causing the downstream crash
}

My PR (#24537) adds this to edit.ts. I will also apply the same fix to write.ts since the screenshot confirms it's affected too.

[PratikRai0101]

update on the PR, I did a full audit of the tools suite based on the screenshot. It turns out the exact same missing args property wasn't just affecting edit and write but it was a repo-wide pattern.

I just pushed a follow-up commit that adds the missing args: params payload to the returns for:

write.ts
read.ts (all 3 return paths)
apply_patch.ts
lsp.ts
bash.ts
glob.ts
grep.ts

The entire file modifying tool suite is now patched to prevent this downstream crash from happening anywhere else.

[SuyeshBadge]

@PratikRai0101, were you able to reproduce this issue on your end?

[PratikRai0101]

@SuyeshBadge Yes, I was able to reproduce and verify the issue.

I added targeted reproduction tests that assert result.args.filePath exists on the tool output. These tests fail on the old code and pass with the fix applied:

Test 1 — New file creation (oldString === ""):

const result = await edit.execute({ filePath: filepath, oldString: "", newString: "new content" }, ctx)
expect(result.args).toBeDefined()           // ❌ fails without fix
expect(result.args.filePath).toBe(filepath) // ❌ fails without fix

Test 2 — Existing file modification (oldString !== ""):

const result = await edit.execute({ filePath: filepath, oldString: "old content", newString: "new content" }, ctx)
expect(result.args).toBeDefined()           // ❌ fails without fix
expect(result.args.filePath).toBe(filepath) // ❌ fails without fix

Before the fix: The edit tool returned { metadata, title, output } with no args field. Any downstream code accessing output.args.filePath would throw undefined is not an object.

After the fix: The tool now returns { metadata, title, output, args: params }, which includes the original input arguments. Both tests pass, and the crash is resolved.

I also verified that write, read, apply_patch, lsp, bash, glob, and grep tools had the same issue and fixed them in PR #24537.

[SuyeshBadge]

@rekram1-node, could we please prioritize this? I believe others may also be affected by this issue.

[SuyeshBadge]

@rekram1-node @PratikRai0101, if this is going to take longer to fix, could you please help me with a workaround for my local machine so I can avoid encountering this error?

[rekram1-node]

@SuyeshBadge how are u replicating this issue? are u using plugins or something? A custom tool?

[SuyeshBadge]

I am using the OpenCode CLI with a Go subscription only, and I am accessing it through a Coder development workspace. My terminal is Zsh.