Docs/FYI: npx @microsoft/workiq 404s when @microsoft scope is pinned to GitHub Packages (workaround inside)

FYI / docs gap: npx -y @microsoft/workiq@latest fails with 404 when @microsoft scope is pinned to GitHub Packages

Summary
@microsoft/workiq is published to public npm (confirmed: latest = 0.4.1, preview = 0.5.0-preview3 via https://registry.npmjs.org/@microsoft/workiq). However, many Microsoft-internal setups have a user/global .npmrc that pins the whole @microsoft scope to GitHub Packages, because other internal @microsoft/* packages (e.g. @microsoft/msx-mcp-server) live there:

`ini

~/.npmrc

@microsoft:registry=https://npm.pkg.github.com
`

With that mapping in place, the standard install/MCP command resolves WorkIQ against GitHub Packages, where it does not exist, and fails:

npm error 404 Not Found - GET https://npm.pkg.github.com/@microsoft%2fworkiq npm error 404 npm package "workiq" does not exist under owner "microsoft"

This is easy to miss because the package genuinely is published — just to a different registry than the user's @microsoft scope mapping points to. It bit us in a GitHub Copilot CLI / VS Code MCP setup where @microsoft/msx-mcp-server (GitHub Packages) and @microsoft/workiq (public npm) coexist under the same scope.

Repro

1. Set @microsoft:registry=https://npm.pkg.github.com in ~/.npmrc (common when consuming other internal @microsoft feeds).
2. Run npx -y @microsoft/workiq@latest mcp (or the documented MCP server config).
3. → 404 from npm.pkg.github.com; the MCP server never starts.

Workaround that fixed it for us
Point WorkIQ's invocation at its own npm config so the @microsoft scope routes to public npm for this server only, without disturbing the GitHub Packages mapping other internal packages need:

• A dedicated workiq.npmrc:
  ini @microsoft:registry=https://registry.npmjs.org/ registry=https://registry.npmjs.org/
• MCP server env:
  json "workiq": { "command": "npx", "args": ["-y", "@microsoft/workiq@latest", "mcp"], "env": { "npm_config_userconfig": "/abs/path/to/workiq.npmrc" } }
  (We found a bare "npm_config_@microsoft:registry": "https://registry.npmjs.org/" env override less reliable than pointing userconfig at a dedicated file.)

Suggestion
A short note in the README's Standalone MCP Installation / Troubleshooting section — "if your @microsoft scope is mapped to a private feed, WorkIQ may 404; route @microsoft to registry.npmjs.org for the WorkIQ invocation" — would save folks the diagnosis time. The one-line npm_config_userconfig recipe above could be included.

Thanks for shipping WorkIQ — the M365 signal access is exactly what we want to build on. Happy to PR the README note if useful.

Open the README's Standalone MCP Installation and Troubleshooting sections. Review the existing npx/MCP configuration guidance alongside the provided dedicated workiq.npmrc and npm_config_userconfig workaround. Done means the README explains the private @microsoft registry 404 and includes a usable per-invocation recipe.