Claude Code vs ISFS. Has anyone cracked how to get one to see the other?
I'm starting to play more with AI enabled coding.
I've been using Github Copilot inside Visual studio code, which is very good at coming up with autocomplete suggestions that are accurate and useful. (Along with some utter rubbish, naturally).
For web development I'm starting to use Claude Code in VS Code to help create web sites and integrations. I want to see how it can help with IRIS development.
However I can't get claude to read any iris code directly as I'm connected to my server via isfs server connections. Asking Claude about it gives an answer that it can't read the files, despite them being displayed in the editor.
A quick example on an open class file:
I can't locate the file — the path C:\SalesLedger\PrintStatement.cls doesn't appear to exist on disk from my perspective. Could you share the file path as it appears in your file explorer, or paste the file contents directly here?
Since I don't want to change the way I'm working with the IRIS files, (as in keeping them on the remote server, using deltanji for source control), does anyone have any suggestions on how I might be able to have Claude see the files.
Copying and pasting the file contents to a chat window is not going to be a usable workflow so despite it's suggestion that's a non starter.
Claudes answer to this was as follows:
The additional complication for you specifically is the InterSystems setup. Claude Code works with files on your local filesystem or in a terminal-accessible workspace. Files held on an IRIS server accessed via InterSystems Server Manager are presented in VS Code through a virtual filesystem (the isfs:// scheme) — they don't sit on local disk. Claude Code is unlikely to interact cleanly with those files since it can't reach them via normal filesystem tools or the terminal.
Practical options worth considering:
- For agentic/chat-style help: Claude Code is fine for discussing your ObjectScript logic, reviewing code you paste in, or helping you write classes — just not for directly editing server-side files autonomously.
- For true inline autocomplete with Claude's models: The Continue extension (separate from Claude Code) supports Claude via the Anthropic API and does provide Copilot-style ghost text completions. It's worth a look if autocomplete is what you're after.
- Keep Copilot for autocomplete, add Claude Code for bigger tasks: VS Code's own multi-agent vision positions these tools as complementary — use Copilot for autocomplete-style assistance and Claude Code for complex reasoning tasks.
Given the IRIS/virtual filesystem constraint, you may find Claude Code most useful as a thinking partner and code generator that you then paste into the VS Code editor, rather than an agent that edits your server-side files directly. Would you like help configuring any of these options?
I asked for clarification on option 2 and it walked back the idea as apparently the product no longer, (5 minutes later), does what claude suggested it did!
Comments
@Mark Charlton This is blocked by VS Code issue #227970, which is dependent on the VS Code team finalizing the two proposed APIs that our main extension consumes. We do not know when this will be resolved. The best way to develop with AI and IRIS is to get your files on the local file system and edit them there (what we call "client-side editing"). AI tools are very good at working with files.
Thanks for the update. I figured it would most likely be down to the file exposure from the VS Code team. I wasn't sure if there was any clever work arounds to get that visibility. I know the community can be inventive!
I'll cross my fingers and hope they get a move on then. I don't really want my files client side, and as of yet, the AI benefit isn't high enough to justify the change of strategy, but we'll see how that goes with time.
Hi Mark,
We ran into this exact same wall. Large IRIS codebase, server-side source control, and Claude Code completely blind to everything behind isfs://.
What ended up working for us was a completely different angle: instead of trying to make Claude see the VS Code virtual filesystem, we built an MCP server that wraps the Atelier REST API, the same /api/atelier/v1/ endpoints that VS Code's ObjectScript extension already uses under the hood.
MCP (Model Context Protocol) is basically a way to give AI tools like Claude Code access to external tools they can call on their own. So now Claude has direct access to IRIS: it can read documents, write them, search across all classes and routines, get class metadata, compile, run SQL queries, check ^ERRORS for debugging, and so on. Around 20 tools in total.
- iris_read_document / iris_write_document — Read and write full classes, routines, includes, etc.
- iris_edit_document — Find/replace within a document on the server, without needing to transfer the full content back and forth. This is incredibly efficient for small edits.
- iris_compile — Compile one or more documents and get compilation errors back.
- iris_search — Full-text search across all documents (classes, routines, includes, CSP pages). Essential for Claude to understand how things connect.
- iris_list_documents — List and filter documents by type and name pattern.
- iris_get_class_info — Get class metadata: properties, methods, parameters, indexes — without reading the raw source.
- iris_read_method — Read just one method from a class. Much more efficient than reading the entire class when Claude only needs to check one method.
- iris_get_class_hierarchy — Explore superclass/subclass relationships.
- iris_execute_query — Run SQL queries (read-only SELECT) directly on the server.
- iris_explain_query — Get SQL execution plans for query optimization.
- iris_call_classmethod — Execute ClassMethods via REST.
- iris_view_errors — Read the ^ERRORS global for debugging.
- iris_server_info — Get server version, available namespaces, etc.
One tool that turned out to be surprisingly useful is a find/replace edit operation that runs server-side — Claude sends the old string and the new string, and the server does the swap without transferring the full document back and forth. Much more efficient for small changes than reading the whole class, modifying it locally, and writing it back.
The practical result is that Claude can now do the full cycle autonomously: search the codebase to understand the context, read the relevant methods, make edits, compile, and report back any errors. All server-side, no local files involved.
The big win for us was that we didn't have to change our workflow at all. Code stays on the server, source control keeps working as before, no sync headaches. Claude just talks to IRIS directly.
The MCP server itself is a Node.js app — nothing too exotic.
This sounds like what @Jinyao did here:
https://community.intersystems.com/post/no-hallucinate-mcp-real-time-routine-context-objectscript
Have you published your MCP server?
It's very much a proof of concept, not a polished package, but the core idea works well in practice. A typical flow: Claude uses iris_search to locate relevant classes, iris_read_method to understand what they do, iris_edit_document to make a change, and iris_compile to verify it. All server-side. Source and installation instructions here: https://github.com/esalas-devel/iris-mcp-atelier
Happy for people to fork it and make it better — there's plenty that could be hardened or extended.
Hi Mark!
@Brett Saviano is right that client-side editing is the cleanest long-term answer — if you can get your code on disk, do that, and Claude Code works great with local files. But I know there are cases where that's not practical: large server-side codebases with existing source control hooks, production systems where a sync workflow would be disruptive, or legacy .mac routines that were never meant to leave the server.
For those cases, @Ernest Salas's MCP server looks like a great solution -- worth starting there if you want a full MCP setup.
If you want something even lighter — no Node.js install, no server to run — there's a zero-dependency option. The Atelier REST API is just HTTP, and you can hand Claude Code two markdown skill files that tell it how to use curl directly. Nothing to install beyond what's already on your machine:
mkdir -p .claude/skills/compile .claude/skills/introspect
curl -sL "https://gist.githubusercontent.com/isc-tdyar/31061a6024ab104d46c470a93ae4962a/raw/compile.md" \
> .claude/skills/compile/SKILL.md
curl -sL "https://gist.githubusercontent.com/isc-tdyar/31061a6024ab104d46c470a93ae4962a/raw/introspect.md" \
> .claude/skills/introspect/SKILL.md
Then tell Claude your IRIS web port (default 52773, or docker port <container> 52773 for Docker) and it handles the rest — reads source, writes back, compiles, returns errors. The skills cover the 409 / ?ignoreConflict=1 pattern so Claude doesn't get confused by Atelier's concurrency check.
I tested it on IRIS 2025.1 with Claude Sonnet 4.6 on a .mac routine — read, identified bugs, fixed, compiled clean in one pass with the skill loaded. Without the skill, it took four extra round-trips guessing at API versions before converging.
Gist: https://gist.github.com/isc-tdyar/31061a6024ab104d46c470a93ae4962a
Hey :)
That sounds like exactly what I was looking for.
Mac files, so many mac files, buckets and boxes and mountains of macs.
I shall give that a go and see how I get on.
Thanks
@Thomas Dyar this is amazing! Do you want to share the skill on https://openexchange.intersystems.com?