WorkIQ OAuth callback returns 404 only when Copilot CLI runs in WSL

Describe the bug

Summary

WorkIQ authentication fails when GitHub Copilot CLI runs inside WSL2.

The same WorkIQ authentication flow succeeds when GitHub Copilot CLI runs natively on Windows. The failure occurs only when Copilot CLI runs inside WSL2.

After completing Microsoft Entra sign-in, the loopback callback includes valid code and state parameters but returns 404 Not Found.

Environment

• GitHub Copilot CLI: 1.0.80
• WorkIQ plugin: 2.0.0
• WSL: 2.7.1.11
• Kernel: 6.1.18.3-2
• Windows: 10.0.26200.9106
• Ubuntu: 26.04

Steps to reproduce

1. Run copilot inside WSL.

2. Enable the WorkIQ plugin.

3. Trigger a WorkIQ tool call, causing authentication to start.

4. Open the Microsoft Entra authorization URL displayed by Copilot and complete sign-in.

5. The browser redirects to:

   text http://127.0.0.1:12798/?code=...&state=...

Actual behavior

The callback URL returns:

HTTP/1.1 404 Not Found
Content-Type: text/plain

Not Found

Additional observations:

• The callback includes both  code  and  state .
• The callback is reachable from Windows and WSL.
•  ss -ltnp 'sport = :12798'  shows that  copilot  itself owns  127.0.0.1:12798 .
• Calling the complete callback URL from WSL with  curl  also returns  404 Not Found .
• Restarting Copilot and shutting down WSL do not resolve the issue.
• Clearing the persisted WorkIQ OAuth configuration/cache does not change the behavior.

Expected behavior

When running under WSL2, Copilot CLI should handle the WorkIQ OAuth callback as it does when running natively on Windows: associate the valid  code  and  state  with the pending OAuth transaction and exchange the authorization code successfully.

Related context

This may be related to WSL support in  microsoft/work-iq#15 , but differs from callback-reachability issues: here the loopback callback is reachable and handled by the Copilot process itself, which returns  404 .

Affected version

No response

Steps to reproduce the behavior

1. Run copilot inside WSL.

2. Enable the WorkIQ plugin.

3. Trigger a WorkIQ tool call, causing authentication to start.

4. Open the Microsoft Entra authorization URL displayed by Copilot and complete sign-in.

5. The browser redirects to:

   ```text http://127.0.0.1:12798/?code=...&state=...````

Actual behavior

The callback URL returns:

HTTP/1.1 404 Not Found
Content-Type: text/plain

Not Found

Expected behavior

When running under WSL2, Copilot CLI should handle the WorkIQ OAuth callback as it does when running natively on Windows: associate the valid  code  and  state  with the pending OAuth transaction and exchange the authorization code successfully.

Additional context

This may be related to WSL support in https://github.com/microsoft/work-iq/issues/15 , but differs from callback-reachability issues: here the loopback callback is reachable and handled by the Copilot process itself, which returns 404 .

Start with the WorkIQ OAuth callback at http://127.0.0.1:12798/ and reproduce the flow from Copilot CLI inside WSL2, using curl and ss as described. Compare the callback handling with the native Windows flow and verify that valid code and state parameters are associated with the pending transaction, the authorization code is exchanged, and the callback no longer returns 404.