Skip to content

Conversation

@simonferquel
Copy link
Contributor

When cagent is run from within a vs code terminal, use the vscode diff to review edit_tool changes.

Diff.in.VS.Code.mp4

@simonferquel simonferquel requested a review from a team as a code owner January 20, 2026 11:29
@krissetto
Copy link
Contributor

i think we should not render the diff at all in the terminal when showing in vscode, the background of that dialog seems broken

@simonferquel
Copy link
Contributor Author

I checked and have the same rendering from outside vscode.
I have

export CAGENT_EXPERIMENTAL_MARKDOWN_RENDERER=1
export CAGENT_EXPERIMENTAL_DEBUG_LAYOUT=1

@simonferquel
Copy link
Contributor Author

Even dumber: attached a debugger and found that the model is generating edits that... do not modify anything:
image

@krissetto
Copy link
Contributor

Needs a rebase then i'll approve, just gave it a test

i think we should not render the diff at all in the terminal when showing in vscode, the background of that dialog seems broken

What i meant is also that BOTH the TUI and vscode are rendering the diff right now, which is harmless i guess :)

Screenshot From 2026-01-20 16-34-48

Another nit: when using vscode insiders, cagent will detect normal vscode and open that in a separate window. Also not a blocker for this, just something to think about

image

@simonferquel
Copy link
Contributor Author

yes, vscode insider and cursor detection are not easy. I'll try to find a better way to handle that.
also, I want to show that when a write_file tool is invoked and it will overwrite an existing file (for now we do not show anything in that case)

@simonferquel
Copy link
Contributor Author

also, I'd like to have a followup so that you can "always review file changes" in vscode even if you are not running within the editor

@jeanlaurent
Copy link
Member

/review

Copy link
Contributor

@github-actions github-actions bot left a comment

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Code Review Summary

Found 3 issues in the new VSCode diff integration code:

🔴 High Severity (1)

  • Sequential edit application will fail for multiple edits affecting nearby text

🟡 Medium Severity (2)

  • Goroutine leak with no cancellation mechanism
  • External command execution without context for cancellation

Please address the high severity issue before merging. The medium severity issues should also be fixed to enable graceful shutdown.

}
modifiedContent := string(originalContent)
for _, edit := range args.Edits {
modifiedContent = strings.Replace(modifiedContent, edit.OldText, edit.NewText, 1)
Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

🔴 HIGH: Incorrect edit application logic

Applying edits sequentially using strings.Replace(modifiedContent, edit.OldText, edit.NewText, 1) in a loop is incorrect. Each edit is applied to the result of the previous edit, which means:

  1. If edit Remove release/signing workflow #2's OldText is near edit Telemetry #1's changes, it may not be found in the modified content
  2. Edits that overlap or affect nearby regions will produce incorrect results
  3. The order of edits will matter when it shouldn't

This will cause the VSCode diff viewer to show incorrect changes to the user.

Recommended fix: Apply edits based on their original positions in the file, not sequentially. Consider using a proper diff/patch algorithm or applying edits from end-to-beginning to avoid position shifts.

// if already loaded, do nothing else, start the diff process
if !loaded {
go todo.(func())()
}
Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

🟡 MEDIUM: Goroutine leak - no cancellation mechanism

The goroutine go todo.(func())() launches an external editor process with no way to cancel it. If the application exits while the editor is still open:

  1. The goroutine cannot be stopped
  2. Temp files may not be cleaned up if the process is killed
  3. The application cannot gracefully shut down while editors are open

Recommended fix: Pass a context that can be cancelled on application shutdown. Store running goroutines and cancel them during cleanup.

return
}
// wd is for diff + wait for editor to close. This makes sure we delete the temp dir only after editing is done.
if err := exec.Command(externalTool, "-wd", path, tempFilePath).Run(); err != nil {
Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

🟡 MEDIUM: No context for command execution

exec.Command(externalTool, "-wd", path, tempFilePath).Run() runs without a context for cancellation. If the editor hangs or the user wants to exit the application, there's no way to terminate this command.

Recommended fix: Use exec.CommandContext(ctx, externalTool, "-wd", path, tempFilePath).Run() with a cancellable context.

@dgageot
Copy link
Member

dgageot commented Feb 1, 2026

@simonferquel @krissetto what's the status on this one?

@krissetto
Copy link
Contributor

not sure i think @simonferquel wanted to implement further support, but we should probably just get vscode in for now then add more support later

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment

Labels

None yet

Projects

None yet

Development

Successfully merging this pull request may close these issues.

4 participants