AI: edit_file does not respect the current state

[phreed]

Summary

AI: edit_file does not respect the current state

Description

Here is my interaction with the AI.

The Problem: When I use the edit_file tool, it's not making the changes I intend. Instead of properly editing the file, it seems to be reverting to some previous state or not applying the edits correctly. This is why you keep seeing me "throw away" the version catalog work.

What I think is happening:

1. I use edit_file to make changes
2. The tool reports "No edits were made" or makes unexpected changes
3. Instead of debugging why the edit tool isn't working, I panic and try other approaches
4. This leads to me deleting files, recreating them, or reverting to backups
5. Each time I lose the progress toward using the version catalog

The correct approach should be:

1. Identify the specific hardcoded dependencies that need to be replaced
2. Replace them systematically with libs.* references
3. NOT delete or recreate the entire file
4. NOT revert to older versions
   THERE'S THE PROBLEM!

The edit_file tool is reverting all the version catalog changes I made with sed! Look at what happened:

1. My sed commands successfully converted the dependencies to use libs.* references
2. When I called edit_file (even for a simple test), it reverted everything back to hardcoded versions
3. It also reverted the plugins section back to hardcoded versions
4. AND it broke the syntax (removed a closing brace)

This explains everything! Every time I've used edit_file, it's been loading some cached or previous version of the file and overwriting my changes.

The issue seems to be:

• The edit_file tool is not reading the current state of the file from disk
• It's using some cached/stale version
• When it "edits", it's applying changes to the old version and overwriting the current file

For reporting to Zed: This is a critical bug where the edit_file tool doesn't respect the current file state on disk and overwrites manual changes with a stale cached version.
Expected Behavior:
Actual Behavior:

Model Provider Details

• Provider: Anthropic via ZedPro, Caude Sonnet 4
• Model Name:
• Mode: Agent Panel
• Other Details : working on a gradle project, specifically the problem arises when modifiying the 'build.gradle.kts' dependencies.

Zed Version and System Specs

Zed: v0.202.7 (Zed)
OS: Linux Wayland bluefin 42
Memory: 93.8 GiB
Architecture: x86_64
GPU: Intel(R) Arc(tm) Graphics (MTL) || Intel open-source Mesa driver || Mesa 25.1.7

[phreed]

Here is some more detail:

---

Bug Report: Kotlin Language Server interferes with edit_file tool causing data loss and file reversions

Summary:
When the Kotlin Language Server is enabled, Zed's edit_file tool exhibits severe malfunctioning behavior on build.gradle.kts files, causing unwanted changes, data loss, and file reversions to cached/stale versions.

Environment:

• OS: Linux
• File type: build.gradle.kts (Kotlin Gradle build script)
• LSP: kotlin-language-server configured in .zed/settings.json

Reproduction Steps:

1. Open a project with a build.gradle.kts file
2. Configure Kotlin Language Server in .zed/settings.json:

   {
     "lsp": {
       "kotlin-language-server": {
         "settings": {
           "compiler": {
             "jvm": {
               "target": "17"
             }
           }
         }
       }
     }
   }

3. Make manual changes to build.gradle.kts (e.g., replace hardcoded dependency versions with Gradle version catalog references)
4. Attempt any edit using edit_file tool, even adding a simple comment

Expected Behavior:
The edit_file tool should make only the requested changes to the current file state on disk.

Actual Behavior:

• The tool reverts all manual changes back to an old cached version
• Makes massive unwanted modifications (e.g., changing plugin versions, reverting dependency references, adding unrequested code)
• Sometimes reports "No edits were made" when changes should have been applied
• Completely ignores the current file state on disk

Key Evidence:

• File on disk: kotlin("multiplatform") version "2.2.0" (current)
• After edit_file: kotlin("multiplatform") version "2.1.0" (reverted to old version)
• Manual version catalog changes: Completely reverted to hardcoded versions
• Other Kotlin files: edit_file works normally on regular .kt source files

Workaround Discovered:
Setting "enable_language_server": false in .zed/settings.json completely resolves the issue. With LSP disabled, edit_file works correctly and makes only the requested changes.

Root Cause Analysis:
The Kotlin Language Server appears to maintain its own cached version of build.gradle.kts files and interferes with file editing operations, overriding changes with stale data.

Impact:

• Critical data loss risk: Manual work gets silently reverted
• Development workflow disruption: Cannot reliably edit Gradle build files
• Tool unreliability: edit_file becomes unusable for Kotlin projects with LSP enabled

Expected Fix:
The edit_file tool should either:

1. Coordinate with LSP servers to ensure file state consistency, or
2. Temporarily disable LSP interference during editing operations, or
3. Always read the actual file state from disk rather than from LSP caches

This appears to be a critical integration issue between Zed's editing tools and language server protocol implementation.

[phreed]

The work-around is to change the .zed/settings.json:

{
  "enable_language_server": false
}

But of course this prevents the language server from helping.

[phreed]

I have another bug, not part of a community tool this time but still edit_file.

Title**: edit_file tool fails silently on YAML files with language server directives

Environment:

• OS: Linux
• Zed version: [Please fill in your version]
• Shell: /bin/bash

Bug Description:
The edit_file tool in Zed's AI assistant fails silently when attempting to edit YAML files that contain YAML language server directives at the beginning of the file. The tool returns "No edits were made" regardless of the edit request validity, but works correctly once the language server directive is removed.

Impact:
This significantly affects productivity when working with conda-forge recipes, GitHub Actions workflows, and other YAML files that commonly include language server configuration directives for enhanced IDE support.

Reproduction Steps:

1. Create a YAML file with the following content:

# yaml-language-server: $schema=https://raw.githubusercontent.com/prefix-dev/recipe-format/main/schema.json
schema_version: 1

package:
  name: example
  version: "1.0.0"

2. Attempt to use the edit_file tool to make any edit (e.g., change version number, add a comment, etc.)

3. Observe that the tool returns "No edits were made" without making any changes

4. Remove the # yaml-language-server: line from the file

5. Retry the same edit operation - it now works correctly

Expected Behavior:
The edit_file tool should successfully process edit requests on YAML files regardless of the presence of language server directives.

Actual Behavior:
The tool fails silently and returns "No edits were made" when language server directives are present.

Additional Context:

• This issue was encountered while working on conda-forge recipe files in the staged-recipes repository
• The specific schema URL doesn't seem to matter - the issue appears to be triggered by the presence of any # yaml-language-server: directive
• Other editing tools (like terminal sed commands) work fine on the same files
• The issue is immediately resolved by removing the language server directive, suggesting it's specifically related to how the edit tool parses or processes files with this header

Workaround:
Temporarily remove the language server directive, perform edits, then re-add the directive if needed.

Files that commonly exhibit this issue:

• Conda-forge recipe.yaml files
• GitHub Actions workflow files with schema validation
• Other YAML configuration files using language server features

[notpeter]

Closing in favor of:

• Bug: Kotlin Language Server interferes with edit_file tool causing data loss and file reversions zed-extensions/kotlin#44