feat(hashline): add hashline edit tool with experimental flags

[watzon]

Summary

Adds an experimental hashline edit mode for line-anchored edits with stale-anchor protection, and wires it through tool selection + CLI/TUI surfaces.

• hashline mode now ships through the existing edit tool ID (not a separate hashline tool), with schema switching when enabled
• adds hashline operations (set_line, replace_lines, insert_after, replace) and mismatch remap diagnostics
• enables hashline-gated edit behavior via OPENCODE_EXPERIMENTAL_HASHLINE / OPENCODE_EXPERIMENTAL_EDIT
• keeps GPT behavior aligned with existing apply_patch flow
• updates read output to emit LINE:HASH|content when hashline mode is enabled
• extends tests for tool selection and replace behavior (all: true, no-op replace rejection)

Verification

• bun test test/tool/hashline-mode-selection.test.ts test/tool/hashline.test.ts
• bun run typecheck
• bun run build
• pre-push typecheck hook passed

Sources used for hashline implementation

• Internal implementation references:
  • packages/opencode/src/tool/hashline.ts
  • packages/opencode/src/tool/registry.ts
  • packages/opencode/src/tool/read.ts
  • packages/opencode/src/flag/flag.ts
  • packages/opencode/src/cli/cmd/run.ts
  • packages/opencode/src/cli/cmd/tui/routes/session/index.tsx
• Internal test references:
  • packages/opencode/test/tool/hashline.test.ts
  • packages/opencode/test/tool/hashline-mode-selection.test.ts

Fixes#13393

[IndianBoy42]

I'm trying out this PR, lets see how this goes (stream of consciousness sorry)

My first thought it that this shouldn't be called hashline for the ai agent, its just an edit tool with a different format. it 'knows' the verb edit very well, the name hashline is inscrutable.

1. This note in the thinking is interesting:

More edit errors than I hoped

One problem may be that the agent likes to use cat instead of the read tool many times, which doesnt give it the anchors

maybe the tool call failures tell us something: https://gist.github.com/IndianBoy42/9b87950e8845d36eea448cf318674425

is this because its minimax-2.5-free? need to try more with kimi. well kimi had no problems at all

MiniMax2.5 made a few changes: https://github.com/IndianBoy42/opencode

the key one is just calling the tool edit and a few more instructions inspired by oh-my-pi (its more verbose but because this is a relatively new format it may be necessary)

[watzon]

I agree @IndianBoy42. Want to check out the changes?

[ars-ppi]

@watzon I guess this PR will not be merged as the core toolings should remain the same. Therefore this PR was merged #4956 and I created this Plugin for Opencode that needs a bit of tweaking and tuning and some benchmarks but is the way to go: https://github.com/ASidorenkoCode/openhashline

[IndianBoy42]

It is disappointing that that plugin no longer implements hashline editing. I don't think token savings was ever the goal of that, rather just reducing the errors in the tool calls, which you no longer benchmark. I like the architecture of building it as a plugin, that was my first instinct too but it didn't seem possible

[kldzj]

There also is izzzzzi/opencode-hashline (and #13664)

[izzzzzi]

Hi! Author of the opencode-hashline plugin here.

Just wanted to clarify a couple of points:

1. The plugin does implement hashline editing — it registers a hashline_edit tool with full
   replace/delete/insert operations via hash references like 5:a3f.
2. Correctness is benchmarked. We ran both approaches on 60 fixtures from react-edit-benchmark —
   hashline scores 60/60 (100%) vs str_replace at 58/60 (96.7%). str_replace fails on duplicate lines
   (repeated guard clauses, similar code blocks), which hashline handles unambiguously. You can
   reproduce it with npx tsx benchmark/run.ts.
3. The main value is raising the floor for weaker models. Top-tier models like Sonnet 4 or Opus
   handle str_replace reasonably well, but smaller/cheaper models (Haiku, GPT-4o-mini, Gemini Flash,
   etc.) struggle significantly with ambiguous matches and off-by-one errors. Hashline eliminates that
   class of errors entirely by making line addressing exact and unambiguous — it lets you use faster,
   cheaper models without sacrificing edit reliability.
4. Token overhead is documented transparently — hashline adds ~40% overhead (~3 tokens/line). We
   never claimed token savings; for a typical 200-line file, that's ~600 extra tokens — negligible in a
   200K context window, and a worthwhile trade-off for deterministic edits.

Details: https://github.com/izzzzzi/opencode-hashline#benchmark

[github-actions]

Closing this pull request because it has had no updates for more than 60 days. If you plan to continue working on it, feel free to reopen or open a new PR.