Summary
On Windows 11, WolframLanguageContext fails when Wolfram user/cache directories are under a non-ASCII username path, for example，when using a Chinese username:
Basic Wolfram kernel evaluation through MCP works, but Chatbook documentation/context lookup fails while loading vector database files from the local object base.
The failure appears related to WXF/vector database loading on non-ASCII Windows paths:
Developer`ReadWXFFileDeveloper`WriteWXFFileVectorDatabaseObjectVectorDatabasesWOLFRAM_LOCALBASE
Environment
OS: Windows 11
Wolfram / Mathematica: 14.3.0 for Microsoft Windows (64-bit)
SystemID: Windows-x86-64
AgentTools: Wolfram/AgentTools 2.1.0
Chatbook: Wolfram/Chatbook 2.5.0
MCP client: Codex Desktop
MCP server: WolframLanguage
Default user path: C:\Users\甲乙丙\...
Default generated environment:
WOLFRAM_USERBASE = C:\Users\甲乙丙\AppData\Roaming\Wolfram
WOLFRAM_LOCALBASE = C:\Users\甲乙丙\AppData\Roaming\Wolfram\Objects
APPDATA = C:\Users\甲乙丙\AppData\Roaming
Observed Behavior
Basic evaluation works:
<|"KernelVersion" -> $Version, "SystemID" -> $SystemID, "Check" -> 2 + 2|>
returns:
<|"KernelVersion" -> "14.3.0 for Microsoft Windows (64-bit) (July 8, 2025)",
"SystemID" -> "Windows-x86-64",
"Check" -> 4|>
But Calling WolframLanguageContext through the MCP server fails during the Chatbook documentation/context lookup step:
[Error] An unexpected error occurred:
AgentTools::Internal::Path@@Kernel/Tools/Context.wl:295,18-295,81.
The internal failure log points to Chatbook vector database loading:
Source/Chatbook/PromptGenerators/VectorDatabases.wl:943
The relevant failing operation is:
Developer`ReadWXFFile[file]
The file exists and is valid: BinaryDeserialize[ReadByteArray[file]] succeeds, and the same file succeeds with Developer`ReadWXFFile after being copied to an ASCII-only path.
Workaround
The issue is resolved by running the MCP server with a real ASCII-only WOLFRAM_LOCALBASE:
WOLFRAM_LOCALBASE = C:\Users\Public\Documents\WolframCodex\Objects
and placing the Chatbook vector databases under:
C:\Users\Public\Documents\WolframCodex\Objects\Chatbook\VectorDatabases
Important detail: WOLFRAM_LOCALBASE must be a real ASCII-only directory. A junction/symlink that points back to the original non-ASCII user path is not sufficient, because VectorDatabaseObject can resolve back to the non-ASCII target path.
After this change, WolframLanguageContext succeeds, and the Chatbook vector database files under the new ASCII local base can be loaded normally.The running MCP kernel reports:
Environment["WOLFRAM_LOCALBASE"] -> C:\Users\Public\Documents\WolframCodex\Objects
Chatbook vector database root -> C:\Users\Public\Documents\WolframCodex\Objects\Chatbook\VectorDatabases\14-3
2 + 2 -> 4
Minimal Diagnostic
On Windows 11 with a non-ASCII user path, after installing WolframLanguage, run:
localBase = ExpandFileName @ LocalObject @ $LocalBase;
file = FileNameJoin[
{
localBase,
"Chatbook",
"VectorDatabases",
"14-3",
"SourceSelector",
"Values.wxf"
}
];
{
FileExistsQ[file],
Developer`ReadWXFFile[file],
MatchQ[BinaryDeserialize[ReadByteArray[file]], {__String}]
}Problematic result:
Then copy the same file to an ASCII-only path and test:
Developer`ReadWXFFile["C:\\Users\\Public\\Documents\\SourceSelector-Values-temp.wxf"]
This succeeds on the same file content.
Related Mathematica-side Failure
The same path issue also appeared when running AgentTools installation/configuration from Mathematica itself. The Codex MCP configuration was written successfully, but AgentTools failed while recording the installation:
Developer`WriteWXFFile: cannot access file
C:\Users\甲乙丙\AppData\Roaming\Wolfram\ApplicationData\Wolfram\AgentTools\Servers\WolframLanguage\Installations.wxf
This looks like the write-side counterpart of the same problem: Developer`WriteWXFFile fails under the non-ASCII Windows user path, while the MCP server can otherwise start and the kernel can evaluate Wolfram Language code.
Summary
On Windows 11,
WolframLanguageContextfails when Wolfram user/cache directories are under a non-ASCII username path, for example，when using a Chinese username:Basic Wolfram kernel evaluation through MCP works, but Chatbook documentation/context lookup fails while loading vector database files from the local object base.
The failure appears related to WXF/vector database loading on non-ASCII Windows paths:
Developer`ReadWXFFileDeveloper`WriteWXFFileVectorDatabaseObjectVectorDatabasesWOLFRAM_LOCALBASEEnvironment
Default generated environment:
Observed Behavior
Basic evaluation works:
returns:
But Calling
WolframLanguageContextthrough the MCP server fails during the Chatbook documentation/context lookup step:The internal failure log points to Chatbook vector database loading:
The relevant failing operation is:
The file exists and is valid:
BinaryDeserialize[ReadByteArray[file]]succeeds, and the same file succeeds withDeveloper`ReadWXFFileafter being copied to an ASCII-only path.Workaround
The issue is resolved by running the MCP server with a real ASCII-only
WOLFRAM_LOCALBASE:and placing the Chatbook vector databases under:
Important detail:
WOLFRAM_LOCALBASEmust be a real ASCII-only directory. A junction/symlink that points back to the original non-ASCII user path is not sufficient, becauseVectorDatabaseObjectcan resolve back to the non-ASCII target path.After this change,
WolframLanguageContextsucceeds, and the Chatbook vector database files under the new ASCII local base can be loaded normally.The running MCP kernel reports:Minimal Diagnostic
On Windows 11 with a non-ASCII user path, after installing
WolframLanguage, run:Problematic result:
{True, $Failed, True}Then copy the same file to an ASCII-only path and test:
This succeeds on the same file content.
Related Mathematica-side Failure
The same path issue also appeared when running AgentTools installation/configuration from Mathematica itself. The Codex MCP configuration was written successfully, but AgentTools failed while recording the installation:
This looks like the write-side counterpart of the same problem:
Developer`WriteWXFFilefails under the non-ASCII Windows user path, while the MCP server can otherwise start and the kernel can evaluate Wolfram Language code.