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

[billwhalenmsft]

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.