`agent-shell-devcontainer-resolve-path` throws error in projects without `.devcontainer/devcontainer.json`

[systemfreund]

If agent-shell-path-resolver-function is set globally to #'agent-shell-devcontainer-resolve-path, sessions in projects without .devcontainer/devcontainer.json fail with (error "Not found:"). The resolver unconditionally calls agent-shell-devcontainer--get-workspace-path, and the helper throws an error when the config file is missing.

Practical consequence: Anyone using projects with and without devcontainers in the same Emacs cannot simply set the variable globally, but needs their own wrapper that first checks whether the project is actually a devcontainer project.

Proposal: If no .devcontainer/devcontainer.json exists in the CWD, agent-shell-devcontainer-resolve-path should return the path unchanged. This makes the variable safe to set globally, and devcontainer translation only applies when relevant.

Checklist

• I agree to communicate with the author myself (not AI-generated).
• I've read the README's Filing issues section.
• I'm running the latest versions (fill in below).
  • agent-shell version:
  • acp.el version:
  • ACP package (e.g. claude-agent-acp) version:
  • Agent CLI (e.g. claude, gemini) version:
• For requesting new agent support, I'm including a link to the ACP-capable agent or related ACP package.
• For issues, I'm including ACP traffic (as per README).

[dschrempf]

Not sure if this is related, but when I start agent-shell with Claude Agent ACP, I also get an error:

node:events:486
      throw er; // Unhandled 'error' event
      ^

Error: write EPIPE
    at afterWriteDispatched (node:internal/stream_base_commons:159:15)
    at writeGeneric (node:internal/stream_base_commons:150:3)
    at Socket._writeGeneric (node:net:966:11)
    at Socket._write (node:net:978:8)
    at writeOrBuffer (node:internal/streams/writable:570:12)
    at _write (node:internal/streams/writable:499:10)
    at Writable.write (node:internal/streams/writable:508:10)
    at F9.write (file:///nix/store/c5i4k60ga30zk9vp76ck827djpcv3ah3-claude-agent-acp-0.32.0/lib/node_modules/@agentclientprotocol/claude-agent-acp/node_modules/@anthropic-ai/claude-agent-sdk/sdk.mjs:59:9124)
    at file:///nix/store/c5i4k60ga30zk9vp76ck827djpcv3ah3-claude-agent-acp-0.32.0/lib/node_modules/@agentclientprotocol/claude-agent-acp/node_modules/@anthropic-ai/claude-agent-sdk/sdk.mjs:61:5576
    at new Promise (<anonymous>)
Emitted 'error' event on Socket instance at:
    at emitErrorNT (node:internal/streams/destroy:170:8)
    at emitErrorCloseNT (node:internal/streams/destroy:129:3)
    at process.processTicksAndRejections (node:internal/process/task_queues:90:21) {
  errno: -32,
  code: 'EPIPE',
  syscall: 'write'
}

Node.js v24.14.1

[dschrempf]

(Sorry, my comment is unrelated; this is another issue).

[xenodium]

cc @fritzgrabo

[fritzgrabo]

@systemfreund thanks for reaching out, and sorry for the late reply.

#'agent-shell-devcontainer-resolve-path fails on purpose -- that's a design choice I made when I added support for devcontainers to agent-shell.

My assumption was that, for most users, the reason to run an agent inside a container would be to keep the agent securely isolated from the host system so it can't see sensitive information there, or delete files, etc. -- as a result of that, I wanted the path resolver to fail loudly when a devcontainer.json file could not be found to signal that something is off. I don't just silently want to run the agent outside of a container.

Also, I assumed that different projects would come with different requirements: some might use devcontainers, others might use a purely docker compose-enabled setup. For some other projects, users might want or need to run the agent via TRAMP or even on the host system after all. This is why I'd recommend setting agent-shell-path-resolver-function as a dir-local variable rather than globally.

What do you think, does that make sense -- or do you think a path resolver that fails silently would be the better choice? If so, why?

PS: If dir-locals don't work for you for some reason, you could always use a locally customized version of #'agent-shell-devcontainer-resolve-path, too.

[systemfreund]

Hi, thanks for your reply. I think that makes total sense and I probably opened the issue too prematurely without thinking about it hard enough.

[fritzgrabo]

No worries -- much appreciate you caring enough to reach out to discuss and to even offer a PR 🙌