mxcli version: v0.11.0 (2026-05-21) · OS: Windows 11 · Mendix project: runtime 11.10.0
Summary
Any retrieve/datasource XPath constraint that contains a Mendix system token such as [%CurrentUser%] produces CE0161 "Error(s) in XPath constraint." after the script is applied (verified with Mendix's own mx check). Constraints without a [%…%] token are fine, so the most common real query — "records owned by the current user" — cannot be authored via mxcli.
Minimal repro
Apply this with mxcli exec -p <App.mpr> repro.mdl, then run mx check against the .mpr:
create or modify persistent entity Administration.MxfBase (Title: String(100));
create or modify microflow Administration.Mf_Base ()
begin
retrieve $L from Administration.MxfBase where [Title='abc'];
return;
end;
create or modify persistent entity Administration.MxfTok (Title: String(100));
create or modify microflow Administration.Mf_Tok ()
begin
retrieve $L from Administration.MxfTok where [Title='[%CurrentUser%]'];
return;
end;
Expected
Both retrieves pass mx check. [%CurrentUser%] is a valid Mendix XPath token.
Actual
Mf_Base → clean.Mf_Tok → CE0161 "Error(s) in XPath constraint." at Retrieve … MxfTok.
The same failure occurs for [System.owner='[%CurrentUser%]'] and for the single-quoted ('[Title=''[%CurrentUser%]'']') and double-quoted ("[Title='[%CurrentUser%]']") forms. mxcli exec itself reports no error — only the applied model fails mx check.
Likely cause
The where-clause parser appears to treat the inner [ / ] of the [%token%] as constraint-bracket delimiters (nested-bracket mishandling), so the stored XPath is truncated/corrupted. Isolated cleanly: [Title='abc'] = OK; the only change that flips it to FAIL is adding a [%…%] token, independent of the compared member.
Impact
Blocks every owner-/user-/session-token-filtered retrieve or datasource — a near-universal Mendix pattern ([System.owner='[%CurrentUser%]'], [%CurrentUser%], [%CurrentDateTime%], etc.).
mxcli version:
v0.11.0 (2026-05-21)· OS: Windows 11 · Mendix project: runtime 11.10.0Summary
Any retrieve/datasource XPath constraint that contains a Mendix system token such as
[%CurrentUser%]producesCE0161 "Error(s) in XPath constraint."after the script is applied (verified with Mendix's ownmx check). Constraints without a[%…%]token are fine, so the most common real query — "records owned by the current user" — cannot be authored via mxcli.Minimal repro
Apply this with
mxcli exec -p <App.mpr> repro.mdl, then runmx checkagainst the.mpr:Expected
Both retrieves pass
mx check.[%CurrentUser%]is a valid Mendix XPath token.Actual
Mf_Base→ clean.Mf_Tok→CE0161 "Error(s) in XPath constraint." at Retrieve … MxfTok.The same failure occurs for
[System.owner='[%CurrentUser%]']and for the single-quoted ('[Title=''[%CurrentUser%]'']') and double-quoted ("[Title='[%CurrentUser%]']") forms.mxcli execitself reports no error — only the applied model failsmx check.Likely cause
The where-clause parser appears to treat the inner
[/]of the[%token%]as constraint-bracket delimiters (nested-bracket mishandling), so the stored XPath is truncated/corrupted. Isolated cleanly:[Title='abc']= OK; the only change that flips it to FAIL is adding a[%…%]token, independent of the compared member.Impact
Blocks every owner-/user-/session-token-filtered retrieve or datasource — a near-universal Mendix pattern (
[System.owner='[%CurrentUser%]'],[%CurrentUser%],[%CurrentDateTime%], etc.).