This change will allow for this package to be used directly, without
launching a subprocess and communicating over stdio.
---------
Co-authored-by: Ben Brandt <benjamin.j.brandt@gmail.com>
The ACP spec has the path as a required field for tool call locations,
but I've seen Claude generate read calls without an input path, which
would generate:
```json
{
"content": [],
"kind": "read",
"locations": [
{
"line": 0
}
],
"rawInput": {},
"sessionUpdate": "tool_call",
"status": "pending",
"title": "Read File",
"toolCallId": "toolu_012PzeR5whUjWN4ij2HBubJw"
}
```
And then fail to parse as SessionNotification in the SDK.
We were relying on unreachable to catch stuff for us, but it wasn't
erroring because we were manually casting a few of the types to never,
leading to a bug when a hook response was encountered.
We'll revisit showing these hook responses to the user once ACP supports
multiple types of status messages.
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>
