fix(tool): coerce object arguments to string in edit and write tools

[extrasmall0]

Issue for this PR

Closes #6918

Type of change

• Bug fix

What does this PR do?

Several models (Qwen3-Coder, GLM4.7, Gemini-3-pro-preview, and others) occasionally emit a JSON object rather than a plain string for tool parameters that are supposed to be strings — e.g. oldString / newString in the edit tool or content in the write tool. Zod rejects these outright with:

Error: The edit tool was called with invalid arguments: [
  { "expected": "string", "code": "invalid_type", "path": ["oldString"], "message": "Invalid input: expected string, received object" }
]

This causes the model to loop on the same error indefinitely.

Fix: Add a z.preprocess step on each affected parameter that serialises any incoming object value via JSON.stringify before Zod validates it. Plain string inputs pass through unchanged.

Additionally, reorder the write tool parameters so filePath comes before content, matching edit, read, and apply_patch. Small/quantised models are sensitive to JSON schema property ordering and reliably emit filePath when it appears first — this also addresses the received undefined variant of the write-tool error.

How did you verify your code works?

• Ran existing tests: bun test packages/opencode/test/tool/edit.test.ts — all pass.
• The object-input path can only be triggered by a live misbehaving model; the preprocess logic is straightforward enough that a code review should be sufficient.

Checklist

• I have tested my changes locally
• I have not included unrelated changes in this PR

[github-actions]

The following comment was made by an LLM, it may be inaccurate:

Found potential related PRs:

1. PR fix: put filePath before content in write tool schema #14744 - "fix: put filePath before content in write tool schema"

   • Addresses the parameter ordering issue mentioned in this PR (filePath before content in write tool)

2. PR fix(opencode): write.ts coerce JSON objects to strings #14832 - "fix(opencode): write.ts coerce JSON objects to strings"

   • Directly related to the same issue of coercing JSON objects to strings in the write tool

These PRs appear to address the same or overlapping issues from this PR. PR #14744 and #14832 may have been previous attempts or partial fixes for the problems this PR comprehensively addresses.

[extrasmall0]

The Windows e2e failure appears to be a pre-existing flaky environment issue — I can see it also fails on recently merged PRs (e.g. #21803) that have no relation to this change. All other checks pass (unit Windows/Linux, typecheck, lint). Happy to rebase or add more context if needed.

[extrasmall0]

The Windows e2e job timed out (30 min limit) — looking at the logs it seems like an environment/infra issue rather than something introduced by this PR. The Linux e2e, unit tests on both platforms, and typecheck all pass. Happy to re-trigger if that helps, or let me know if there's something specific you'd like me to look into on the Windows side.

[extrasmall0]

Rebased onto the latest dev (as of today) to resolve the merge conflicts — the fix itself hasn't changed. CI should be green now (the e2e (windows) failure was a pre-existing flake unrelated to this PR, also present on other open PRs).

[rekram1-node]

Automated PR Cleanup

Thank you for contributing to opencode.

Due to the high volume of PRs from users and AI agents, we periodically close older PRs using automated criteria so maintainers can focus review time on the most active and community-supported contributions.

This PR was closed because it matched the following cleanup criteria:

• The PR was created more than 1 month ago
• The PR had fewer than 2 positive reactions
• Positive reactions are counted as thumbs-up, heart, celebration, or rocket reactions on the PR

PRs created within the last month are not affected by this cleanup.

If you believe this PR was closed incorrectly, or if you are still actively working on it, please leave a comment explaining why it should be reopened. A maintainer can review and reopen it if appropriate.

Thanks again for taking the time to contribute.