Hi Emmanuel, no network port is involved. The plugin listens on a Unix domain socket, and the launcher in the agent's sandbox connects to it. Inside the sandbox the agent needs:
1. Java and the launcher: a JDK 17+ and dukehoff-mcp-launcher-<version>.jar, started as the MCP server: java -jar dukehoff-mcp-launcher-<version>.jar --ide. 2. Read access to the registry: ~/.dukehoff-mcp/ide/, where NetBeans writes <pid>.json with the socket path. If the sandbox has a different home, point both sides at a shared folder with the environment variable DUKEHOFF_MCP_IDE_DIR. 3. Permission to connect to the socket: NetBeans creates it in its temp directory as dukehoff-mcp-ide-<random>/ide.sock, readable by its owner only. On Linux that is /tmp, on macOS $TMPDIR, and the exact path is in the JSON. So the sandbox has to allow Unix socket connections there (in Claude Code's sandbox that's allowUnixSockets), and the agent must run as the same user as NetBeans. 4. The same project path: the launcher sends the agent's working directory, and NetBeans matches it against its open projects. In a container the project has to be mounted at the same path as on the host. One limitation for containers: the launcher ignores registry entries whose NetBeans process it can't see; it checks the pid to skip stale entries. In a sandbox with its own PID namespace (e.g. Docker, or bubblewrap with --unshare-pid) it will therefore find no IDE. Plain filesystem/network sandboxes are fine. If that's your setup, tell me and I'll add an option to skip the check, or to name the socket directly. On security: the refactorings are done by NetBeans itself, outside the sandbox, so the sandbox's write rules don't cover them. The plugin limits writes to the agent's folder. Anything outside it is only changed when the agent explicitly allows those paths in the call, which it is told to do only after asking the user. What kind of sandbox are you running? Cheers, Toni Am 19.10.26, 13:08 schrieb "ehsavoie" <[email protected] <mailto:[email protected]>>: Hello, I'm running my agent in a sandbox, what do I need to open to be able to have it communicate with NetBeans ? Cheers, Emmanuel Le lun. 19 oct. 2026 à 09:40, Anton Epple <[email protected] <mailto:[email protected]>> a écrit : > Hi all, > > > > Following up on the discussion around Emmanuel's PR #9712: the Java tools > I mentioned there are now available as a NetBeans plugin, and I'd be glad > if some of you tried them. I’m looking forward to integrate them with > Emmanuel’s work once that is ready, but even without that you can use them > already. > > > > The plugin starts an MCP server inside the running IDE. A coding agent in > a terminal (Claude Code, Codex, Copilot CLI, ...) connects to it and uses > NetBeans' Java infrastructure instead of grep and text edits. It sees the > same index and the projects you have open, and refactorings appear in the > editor right away. The tools: > > > > - find_usages (optionally grouped by calling method), find_implementations > with the override chain, outline (library types included), diagnostics > > - Refactorings: rename, move, change_signature, safe_delete, inline. After > each one the compile check reports any new errors. > > - apply_rule: Jackpot rules written by the agent, or ready-made packs for > JUnit 4→5, javax→jakarta and Java modernization > > - debug: one call that runs a test, stops at a breakpoint or exception and > returns the stack with locals > > > > Addressing Michael's point about harness permissions: Writes stay inside > the agent's working folder. > > > > To try it (NetBeans 31 or newer): > > > > 1. Download dukehoff-mcp-netbeans-0.9.1.nbm from > https://github.com/dukehoff-gmbh/dukehoff-mcp/releases > <https://github.com/dukehoff-gmbh/dukehoff-mcp/releases> and install it via > Tools > Plugins > Downloaded > Add Plugins..., then restart if asked. > > 2. From the same release, download dukehoff-mcp-launcher-<version>.jar and > print the client configuration with java -jar > dukehoff-mcp-launcher-<version>.jar --config claude --ide. > > 3. Open your project in NetBeans and start the agent in its folder. > > > > There is also a standalone headless runtime for agents without an IDE, and > a VS Code extension built on the Apache NetBeans Java extension. The code > is Apache 2.0. Most of it was written with an AI assistant (Claude) under > my direction and review, and the commits disclose that. > > > > A question on distribution: today users install the NBM by hand from > GitHub. I'd like to offer an update center, so they can add it once and get > updates. Where would you recommend hosting it? > > > > - The Plugin Portal (plugins.netbeans.apache.org): is it still the > recommended route for third-party plugins? What does verification per > NetBeans release involve today, and are there signing requirements? > > - A self-hosted catalog (updates.xml next to the GitHub releases, added > under Tools > Plugins > Settings): fine for now, or are there pitfalls > (signing, trust dialogs)? > > - An official plugin repository for faster-moving features like AI > integration, as Neil suggested on the PR thread: is anything like that > planned? Jaroslav, I think you had something in mind as well. > > > > Feedback of any kind is welcome: on the list, as GitHub issues, or > directly to me. > > > > Thanks, > > Toni > > --------------------------------------------------------------------- To unsubscribe, e-mail: [email protected] For additional commands, e-mail: [email protected] For further information about the NetBeans mailing lists, visit: https://cwiki.apache.org/confluence/display/NETBEANS/Mailing+lists
