Windows: msys path-conversion mangles leading-slash SSM param names #156
Loading…
Add table
Add a link
Reference in a new issue
No description provided.
Delete branch "%!s()"
Deleting a branch is permanent. Although the deleted branch may continue to exist for a short time before it actually gets removed, it CANNOT be undone in most cases. Continue?
Problem
On the Windows tower, running Windows-native
coily.exefrom an msys/git-bash shell, any argument that looks like a POSIX absolute path gets rewritten by msys path-conversion before it reaches coily/AWS. This silently mangles leading-slash SSM parameter names.Observed:
coily ops aws ssm get-parameter --name /coilysiren/netlify/token->ParameterNotFound(the leading slash is stripped/rewritten, so AWS looks up a slash-less name that doesn't exist).coily ops aws ssm get-parameters-by-path --path /coilysiren --recursive->ValidationException: The parameter name must begin with a forward slash "/"(single-segment/coilysirengets rewritten to a Windows path likeC:/Program Files/Git/coilysiren, which no longer starts with/).Both resolve correctly when path-conversion is disabled:
This is a real footgun: the failure mode looks like a missing param or a wrong AWS account, when the param is present and the account is correct. It will bite every leading-slash arg on Windows (SSM names, any
/-rooted value), not just Netlify.Asks
coily.exeon Windows so callers don't have to think about it. Options:MSYSTEMset, or running under git-bash) and setMSYS_NO_PATHCONV=1/MSYS2_ARG_CONV_EXCL='*'for childawsinvocations, orC:/...coilysiren...), emit a clear operator notice naming msys path-conversion as the cause, rather than surfacing a rawParameterNotFound/ValidationException.Workaround (in place now)
export MSYS_NO_PATHCONV=1added to the tower shell rc so interactive + agent calls stop mangling. Issue tracks the durable in-binary fix.Origin
Surfaced while wiring a Netlify PAT into SSM for the
coily ops netlifywork (agentic-os-kai#518) on kai-desktop-tower. The token put had actually succeeded; the reads only appeared to fail because of msys path-conversion.