How do I enable the edit tool to use this in OpenCode?

[IshanArya]

Hey,

It seems like my AI still uses the default oldString/newString replacement to call the edit tool in OpenCode.

How can I make it use the hashline version? Do I have to modify the edit tool's declared parameter schema manually or something? How does the AI know to use the hashline tool calls rather than the default ones?

Thanks.

[IshanArya]

For reference, I asked the AI what parameter schema it sees, and it said this:

Looking back at the README and search results, the plugin describes its surfaces as:
Surface Status What happens
read / view public native reads are annotated with stable #HL refs and a REV line
edit public hashline refs are translated into native file edits
write public stays native, with hashline prefixes stripped from nested content fields
And it mentions:

It also adds a small system-instruction hook and annotates file parts that appear in chat messages.
So the plugin works through hooks -- it intercepts tool calls at runtime and transforms arguments. But looking at the Edit tool schema I receive, it still only declares oldString, newString, replaceAll, and filePath. The hashline parameters (operations, startRef, fileRev, etc.) aren't in the schema.
The issue is that the tool schema visible to me (the LLM) defines what parameters I'm allowed to pass. Even if the plugin's hook can handle hashline-style arguments at runtime, I can only send parameters that match the declared schema -- otherwise the tool call gets rejected before the plugin hook even sees it.
The plugin's description field on the Edit tool does hint at hashline support:
"Hashline: Accepts refs copied from read. Prefer one batched call per file with { filePath, fileRev?, operations:[{ op, ref|startRef/endRef, content? }] } instead of many single edits."
That text is in the tool description, which I can read, but the parameter schema doesn't include those fields. The description is guidance for the LLM, but the schema is what validates the actual call.