Closes#98
It turns out we can't always call this right away, as on some machines
the process hasn't initialized yet.
Since available models waits for the process to start, as a workaround
we wait for that first, and then set the permission mode again once we
know that it is ready.
It seems that unless you start the session with bypassPermissions, you
can't change to it later.
So we start with it on, and immediately change it back to default. This
allows people to change it later however.
Closes https://github.com/zed-industries/zed/issues/39392
resolves#90
Tested both the `append` and `override` flows by sending:
```javascript
const resp = await this.connection.newSession({
cwd: basePath,
_meta: {
systemPrompt: "you are an obsidian assistant agent, you should be helpful to the user when working with their notes"
},
mcpServers: []
});
```
```javascript
const resp = await this.connection.newSession({
cwd: basePath,
_meta: {
systemPrompt: {
append: "always speak in spanish"
}
},
mcpServers: []
});
```
and confirmed that in both cases those prompts are what gets sent to the
agent!
---------
Co-authored-by: Ben Brandt <benjamin.j.brandt@gmail.com>
Currently edit requires a permissions call and write does not. This
means that if clients want to allow users to approve `Write` calls they
need to add handling to `HandleFileWrite` but if they do that then edits
get _two_ permissions checks.
Alternatively we could remove the write tool from approved tools (which
would make more sense to me) but I'm assuming its there for a good
reason, if not happy to change to remove it instead!
---------
Co-authored-by: Ben Brandt <benjamin.j.brandt@gmail.com>
When `default`, `acceptEdits`, or `plan` modes fail, users see the real
error from the SDK instead of a generic message.
`Bypass permissions` gets special treatment - it shows both the SDK
error AND explains it needs proper configuration. I couldn't test SDK
thats why I added special treatment for bypass permissions. If you can
test it we can talk further.
Related to: https://github.com/zed-industries/zed/pull/39524 @benbrandt
## Description
Closes#84 by allowing users to set `CLAUDE_CODE_EXECUTABLE` to override
the binary that's used by the claude code SDK. This is key in enterprise
environments where claude CLI has been shimmed in some way.
Allows the client to handle line offsets, rather than loading the entire
file and then slicing it on the agent side.
Signed-off-by: Ben Brandt <benjamin.j.brandt@gmail.com>
Signed-off-by: Ben Brandt <benjamin.j.brandt@gmail.com>
This allows us to use the SDK version of an MCP server for all other
tool calls. Ideally the permission server goes away eventually.
Signed-off-by: Ben Brandt <benjamin.j.brandt@gmail.com>
---------
Signed-off-by: Ben Brandt <benjamin.j.brandt@gmail.com>
It would be nice to also support sending status via hooks when the
compact action is happening (and maybe show something in the UI to show
where compacting happened in the thread) but for now this at least
allows it.
---------
Signed-off-by: Ben Brandt <benjamin.j.brandt@gmail.com>
This looks more reasonable now, because the code is now rendered in a
monospace font:
<img width="475" height="450" alt="Screenshot 2025-09-15 at 10 58 20 AM"
src="https://github.com/user-attachments/assets/9870436b-ee8f-44cd-b814-b22ad9261ebe"
/>
That said, this definitely would benefit from a horizontal scroll bar on
the code blocks. You can't really read what it's saying without copying
the text out of the block.
Of course, in this particular case the relevant info is all in the
beginning of the error message (namely, that it failed to find the
`old_string`), and this does look overall better than before (where it
was just this big jumble of non-monospaced code), so I think it's worth
merging as-is and then revisiting horizontal scrolling later.
