Show Edit Requests inline

[Makesesama]

Current State

Right now the if the agent wants to edit a file agent-shell asks for the tool permission. The user can view it if he wants.

Proposal

Show the change or part of the change as preview in the agent-shell buffer like the default claude-code cli does.

[xenodium]

Thanks for filing a feature request.

Ha! I did not expect this one :) Most folks I've spoken to are happy with the quick-diff buffer momentarily poping up (more room and less clutter), as well as the simple bindings/flow (n/p/q -> y/n/!) to manage the patch.

Are there specific bits about quick-diff that I could improve? I'm saying this as nailing a different diffing flow takes quite a bit of effort and iterations (quick-diff certainly did). I tried a handful of approaches before I landed on quick-diff.

Perhaps you could share more details about the things you like about claude-code cli diffing in addition to being in the same buffer? My hope with quick-diff was to make the transition fairly smooth.

Having said all this, as Emacsers we love the flexibility and options we have. I'm wondering if providing hooks for the edit events would cater for all? quick-diff as default, but can be replaced with another flow preferred by users.

[Makesesama]

Thanks for responding so quickly.

I actually thought a bit before if the quick-diff workflow is really not what i would prefer, because i think it's actually really nice.

Nonetheless i really like seeing what is being done in the overview when using claude-code cli, because my workflow sometimes is, to just let claude-code go and implement a feature or fix a bug and review it afterwards. For that workflow i think actually seeing in which direction the llm is going is important, so i can stop it before the direction is totally wrong.

I also think providing a way to customize this would be the best for something in emacs.

Thanks for the awesome work :)

[xenodium]

Thanks for this. It gives me more context. A couple of things that come to mind:

For that workflow i think actually seeing in which direction the llm is going is important

Is the agent not pausing for you until you accept or reject proposed changes?

I also think providing a way to customize this would be the best for something in emacs.

I'm wondering if the configuration point should be different than what I originally thought... Given you're interested on keeping sight of the agent shell, I'm thinking quick-diff window placement is what we're likely after. What if you could configure where quick-diff pops up to? Side window, bottom window, etc. This way the shell itself remains visible to you.

WDYT?

Thanks for the awesome work :)

Thank you. That's nice to hear. Glad you like it.

[Makesesama]

Is the agent not pausing for you until you accept or reject proposed changes?

Yes normally the agents stops until i accept changes.
As i already said i often like to let the llm run until its finished. This means i am giving it a task, like "please fix this specific little bug i have, these are the informations i have" and then auto-approve all edits. In the meantime i can document this bug more or do other things. If the llm is done with working on this i review the changes in magit and if i have more things to change i get into a feedback loop with the llm or fix them myself.

I'm thinking quick-diff window placement is what we're likely after.

Popping this up automatically on an edit would probably be a nice config option i would definetly use!

I think there are even more things that can be improved for this workflow to work with agent-shell like disabling the auto-edit after it was once enabled (shift-tab on claude-code-cli), maybe with a nice transient interface...

I will probably pull agent-shell tomorrow and hack a bit on it, let's see what comes out of it.

Have you already had a look at claude-code.el? There are many ideas that could be interesting for this package and i think because agent-shell uses acp it could go even further than claude-code.el.

[cmacrae]

Oh, good timing, I've been working on this feature over the last couple days! I was just about to come here to raise an issue to propose the change and show the work I've done on it. Here's a video (with audio) showcasing how the feature works:

Screen.Recording.2025-10-15.at.11.23.57.mov

Changes are on my feat/follow_edits branch. Obviously this is quite a chunk of code with some considerable complexity (it took me a lot of iterating to get it this smooth), so very happy to discuss back and forth on implementation @xenodium

What do you guys think? :) I've been putting it through it's paces and I've found it to be a very nice experience so far, personally

EDIT: Just to add, after reading over the discussion here a little more closely, I realise this "other window" approach I've taken may not entirely align with what you guys are discussing. Early in this feature's development, I had a var the user could set to decide how/where they want the preview to appear. I found "other window" the most natural, as it follows what other IDEs integrating agents do and is personally what I would use. Focus stays in the agent-shell buffer, so the keybindings work, as you can see in the video. If there is interest in this "how/where" option being reintroduced, I could take a stab at it. So, for instance, perhaps some people prefer for this to happen within the agent-shell buffer, briefly overlaying the chat contents with the diff, instead of visiting it in another buffer. That said, this feature is already quite complex, so if there is interest in having this feature accepted, perhaps we get that in first before trying to build on top of it.

[xenodium]

Whoa nice work @cmacrae! That looks wonderful. I can imagine getting to that experience took quite a few interations but also appreciate your care for UX. I know how it is ;)

With regards to agent-shell and its ability to provide different experiences, I'm thinking the most manageable way for me to handle this is to provide hooks, APIs, or different configurable entry points. This enables me to keep the codebase somewhat small/grokable (easier for me to maintain), but also enable folks to extend and provide different experiences in separate packages.

https://github.com/cmacrae/agent-shell-sidebar is the first one to provide additional features as a separate package. I'll link to all packages that do from the agent-shell page.

As you noted, there is a bit of complexity required to achieved that desired experience. If you're keen to build and maintain a separate package, I'm happy to accomodate all the entry points that you may need. In fact, you likely already noticed the current permission-handling code needs some love. What's in there is the result of lots of experimentation, thus needs cleanup. I've been meaning to take care of this (already filed #50). I hope to take of that soon.

Again. Awesome work!

[cmacrae]

Whoa nice work @cmacrae! That looks wonderful. I can imagine getting to that experience took quite a few interations but also appreciate your care for UX. I know how it is ;)

Thanks! Haha, yes, maintaining a nice UX is paramount, especially considering how nice it already is in agent-shell ♥️

With regards to agent-shell and its ability to provide different experiences, I'm thinking the most manageable way for me to handle this is to provide hooks, APIs, or different configurable entry points. This enables me to keep the codebase somewhat small/grokable (easier for me to maintain), but also enable folks to extend and provide different experiences in separate packages.

https://github.com/cmacrae/agent-shell-sidebar is the first one to provide additional features as a separate package. I'll link to all packages that do from the agent-shell page.

Agreed, I think this is definitely the best approach: maintain core mechanisms and features in the main package, providing an API, and expect others to build extension/enhancement packages on top of it 👍

As you noted, there is a bit of complexity required to achieved that desired experience. If you're keen to build and maintain a separate package, I'm happy to accomodate all the entry points that you may need. In fact, you likely already noticed the current permission-handling code needs some love. What's in there is the result of lots of experimentation, thus needs cleanup. I've been meaning to take care of this (already filed #50). I hope to take of that soon.

Again. Awesome work!

Yeah that'd be great! I'll take some time at some point, when I have it, to go over all my code and figure out what I'd need exposing to be able to turn this into its own package 🙏

[ElleNajt]

A UX that I'd find useful is showing the diff below the tool call, in a collapsible section, in the same way that the results of other tool calls are currently shown (e.g. read and bash). This is would be especially useful when I leave claude code in yolo mode or accept all mode, and want to review the history to see the changes it made.

i.e. there should be a triangle next to edit also

@xenodium Do you have takes? Would you be open to a PR that does that?

[xenodium]

@xenodium Do you have takes? Would you be open to a PR that does that?

Possibly, depending on added complexity and the resulting user experience. Unfortunately, I can't really commit to it unless there's a prototype to check out and base decision on. Sorry, I know this is a gamble for you. In the case that the change doesn't land in agent-shell itself, I'm happy to commit to adding the necessary hooks that would enable these sorts of customizations.

As a diverse set of emacsers, we have a diverse preferences on how we use or customize our tools. In other words, it's pretty challenging to build an agent-shell experience that will make everyone happy. Some features will land in agent-shell and others will have to live in separate packages. Hope that makes sense.

[ElleNajt]

Claude one shotted it (okay, two shotted, I had to ask it to add highlighting):

And, yes -- of course makes sense. :) Mostly my motivation rn is just to get all the things I love about claude code into agent-shell or at least my config.

[xenodium]

Thank you. User experience/screenshot looks good to me. Would still need to see some code to gauge added complexity.

[xenodium]

ps. This diff appears in the body after it's been accepted (with or without user intervention), correct?