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
-
Run copilot inside WSL.
-
Enable the WorkIQ plugin.
-
Trigger a WorkIQ tool call, causing authentication to start.
-
Open the Microsoft Entra authorization URL displayed by Copilot and complete sign-in.
-
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
-
Run copilot inside WSL.
-
Enable the WorkIQ plugin.
-
Trigger a WorkIQ tool call, causing authentication to start.
-
Open the Microsoft Entra authorization URL displayed by Copilot and complete sign-in.
-
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 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 .
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
codeandstateparameters but returns404 Not Found.Environment
1.0.802.0.02.7.1.116.1.18.3-210.0.26200.910626.04Steps to reproduce
Run
copilotinside WSL.Enable the WorkIQ plugin.
Trigger a WorkIQ tool call, causing authentication to start.
Open the Microsoft Entra authorization URL displayed by Copilot and complete sign-in.
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
Run
copilotinside WSL.Enable the WorkIQ plugin.
Trigger a WorkIQ tool call, causing authentication to start.
Open the Microsoft Entra authorization URL displayed by Copilot and complete sign-in.
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 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 .