What is required to get Copilot to work with Code for i?

[a4ginatl]

I have a new project and need to use Copilot with VSC. I installed VSC and enabled the IBM i extensions. Copilot was automatically installed.

Problem and questions:

1. What is the best was to get copilot to work with Code for i?
2. Do we need to use a MCP server?
3. Is there a method to get Copilot to work with code for i without using a MCP server? My customer does not allow MCP servers to be used.

Thanks
Darryl.

[croxln]

Hi Darryl,

You definitely do not need an MCP server to use Copilot with Code for IBM i. To address your questions directly:

1. Do you need an MCP server? / Can it work without one?
   No MCP server is needed. MCP is specifically for giving LLMs custom tooling or access to external APIs/services. Standard GitHub Copilot autocomplete and Copilot Chat run completely within VS Code without any MCP servers.

2. What works out of the box:

   • Copilot Chat (inline Ctrl+I or sidebar panel): Works immediately. You can select lines of RPGLE, CL, or COBOL in an open member or reference #editor, and Copilot can explain, refactor, or generate logic for you.
   • Inline Suggestions (Ghost Text) caveat: If you open source members directly from libraries via the virtual member: URI scheme (member:/...), Copilot currently doesn't trigger inline ghost text completions. This is due to an upstream VS Code limitation with non-standard URI schemes (tracked in repo issue Copilot ghost text (inline suggestions) does not work for source members opened via the "member:" scheme #3444 and upstream Inline suggestions (ghost text) never trigger for documents from third-party FileSystemProvider schemes (e.g. Code for IBM i "member:" scheme) microsoft/vscode#335774).

3. Recommended approach without MCP:
   If your team wants full inline ghost-text suggestions while writing code, the standard approach is to keep the sources in a local workspace / git repo (or work via IFS) and use Code for IBM i's built-in Deploy / Actions workflow to compile on the target machine. Because local files use the standard ile: scheme, Copilot autocomplete works seamlessly, fully compliant with your customer's policy against MCP servers.

[VMURAZ20]

Hello,
Yesterday again it was working, Gh copilot was able to modify source code directly from source members opened from Code For i extension. Why is it not working anymore since today ?
Is a tool expected to be worked on Code for i extension to facilitate the code management on IBM i source members directly from Gh copilot chat ?
Thanks

[croxln]

A couple of things to check regarding why this likely changed today:

1. Copilot Chat Update ("Copilot Edits" vs Inline Chat):
   The recent Copilot Chat extension updates introduced the new multi-file "Copilot Edits" mode. The new Edits interface strictly requires files to belong to a local workspace (ile: scheme), which causes it to reject or ignore virtual member: documents.

   • Workaround: If you use Inline Chat (Ctrl+I / Cmd+I) directly inside your open source member editor, Copilot will still modify the code in place just like before.
   • In the sidebar chat, you can also click the "Apply in Editor" button on the top-right of the generated code block to push the diff directly into your active member tab.

2. Check Read-Only / Connection Status:
   Double-check that the member wasn't opened in read-only mode (e.g. lock contention or temporary session drop in Code for i), which prevents Copilot from injecting buffer edits.

3. Regarding an official Copilot tool for Code for i:
   Currently, there isn't a dedicated Copilot Language Model Tool published in Code for i to manipulate remote members directly from prompt commands. The community and maintainers have discussed integrating with VS Code's new Language Model Tool API, but for now, Inline Chat (Ctrl+I) or local workspace deployment remains the standard way to have Copilot edit your code.

[a4ginatl]

Working on individual members is okay, however, when you need to question something in the source files across multiple libraries example, show me the differences in where a field is used from 1 library to another, example version changes, Copilot is not able to do that. Right now we are running our scripts in Claude and Copilot outside of Code4i, but we do need the ability to work in Copilot in Code4i.

[croxln]

That makes complete sense. The reason Copilot struggles with this in Code for i comes down to how Copilot indexes codebases:

Copilot's @workspace indexer strictly relies on files present in your local VS Code workspace folder. When browsing remote libraries through the IBM i tree, the source members remain remote on the host (QSYS.LIB) and are only fetched on-demand when clicked. Because Copilot cannot scan remote libraries across the network without local files, it has no index to trace cross-library field usage or version diffs.

To get cross-library Copilot awareness working natively in Code for i without an MCP server, here are the two most effective workflows:

1. Keep the Source Files in a Local Workspace Folder (Best for Copilot):
   If you download the relevant Source Physical Files into local folders inside your open VS Code workspace (e.g. src/prod/ and src/test/ or via a Git repo):

   • Copilot's @workspace will immediately index every single member across both libraries.
   • You can then directly prompt: @workspace show differences in where field CUSTNO is referenced between prod and test, and Copilot will parse declarations and references across all files locally.
   • You can still compile back to the host seamlessly via Code for i's Deploy & Run Action workflow.

2. Use Code for i's "Search in Source Files" + Copilot Chat:
   If you cannot download members locally:

   • Run Code for IBM i's built-in Search in Source Files (which runs PASE grep across the target libraries on the host).
   • In Copilot Chat, you can paste the search findings or reference the editor to have Copilot analyze the usage patterns.

This is also why some teams look at MCP servers—an MCP server can run host-side SQL (SYSTOOLS.FNDSTRPDM or DB2 catalogs) on the fly for Copilot. But since your customer disallows MCP, having the sources in a local workspace directory is the only way to give Copilot full cross-file indexing capabilities.

[a4ginatl]

If we have the source copied to the IFS, would it help any?

[sebjulliand]

No, unless you download it in your local workspace (in a local folder on your PC).

Copilot only works with what's in the local workspace.

At this point, moving your IBM i source code to Git may be a good option. There are some free and paid tools out there to do that, depending on what you need.

[thomprl]

I've been running into this issue on and off. Sometimes CoPilot is able to see the open member and make suggestions, then something happens and it quits working. Then I get a VSCode update and it will work again and few days later it will stop. I've mostly resorted to basically downloading source to my local. I created an extension for Code For i to help with this process but the ultimate solution is to move to Git or use Bob I think. On my home computer it seems to always work. On my work computer it just comes and goes and I have no idea why. We talked about it here and someone opened a issue with MS. #3444