Windows Copilot CLI repro: VFPOLEDB Execute fails with Class not registered, while the same query succeeds under VS Code

[chin-u]

Describe the bug

MCP server uses JDK 21 x86 + JACOB 1.21 x86 + VFPOLEDB 9.0.
The same legal VFPOLEDB SQL succeeds when the MCP server is hosted by VS Code, but fails when hosted by Copilot CLI.

Affected version

No response

Steps to reproduce the behavior

Repro examples that fail under Copilot CLI:

SELECT COUNT(*) AS cnt FROM patient

SELECT RECNO() AS recno, * FROM patient WHERE RECNO() <= 10

SELECT TOP 10 patient_id, patient_name FROM patient ORDER BY patient_id

Observed error:

Invoke of: Execute
Source: Provider
Description: Class not registered

Expected behavior

No response

Additional context

Diagnostics from the failing path show the runtime is already correct:

execution-context=helper-jvm
host-kind=copilot-cli
x86 / 32-bit JVM
ASCII user.dir
COMSPEC, TEMP, TMP present
VFPOLEDB CLSID present in 32-bit registry
InprocServer32 points to vfpoledb.dll

Representative excerpt:

execution-context=helper-jvm
host-kind=copilot-cli
os.arch=x86
sun.arch.data.model=32
user.dir=C:\Users\REDACTED\AppData\Local\dbf-mcp-runtime
user.dir.ascii?=true
COMSPEC=C:\Windows\System32\cmd.exe
TEMP=C:\Users\REDACTED\AppData\Local\Temp
TMP=C:\Users\REDACTED\AppData\Local\Temp
VFPOLEDB CLSID: view32=true, view64=false
ancestor-commands=java.exe -> java.exe -> copilot.exe -> pwsh.exe -> WindowsTerminal.exe

Also run a helper-side STA probe, and that fails with the same Execute error, so this does not look like a simple MTA vs STA issue.

At this point we have already ruled out:

SQL syntax as the root cause
DBF corruption
wrong JVM bitness
missing VFPOLEDB registration
Unicode cwd
missing TEMP, TMP, or COMSPEC

Current best hypothesis:
under the Copilot CLI host process tree on Windows, VFPOLEDB fails specifically in the Execute / rowset materialization path, likely due to host-context differences, permissions, or a secondary COM dependency triggered only in that host environment.

[chin-u]

Update: HTTP works as a workaround for us, but this does not look fixed.

The 32-bit COM registration still appears valid. The remaining issue seems specific to the Windows Copilot CLI stdio host context, since the same x86 Java + COM path works under VS Code but fails under Copilot CLI. So I am leaving this open unless this scenario is considered out of scope.