Describe the bug
In the GitHub Copilot app, the create_pull_request session tool returns an error for a session running on a remote WSL host, even though the pull request is created successfully:
Failed to create pull request: runtime settings are not configured for this session
After the error:
- The PR exists on GitHub, created at the time of the call, with exactly the title and body passed to the tool.
- The app has linked the PR to the session:
get_session reports created_pr_number and created_pr_state: open, and the session has been renamed to the PR title.
So creating and linking the PR both succeed, and the error comes from some later step. This happens consistently in this setup: the user sees it on essentially every PR opened through the tool.
Impact: the agent treats the call as failed. It either stops to ask the user, or falls back to gh pr create, which then fails with a pull request for branch "<branch>" into branch "main" already exists. Every PR creation costs extra turns and an interruption, and the misleading error invites repeated attempts.
Affected version
GitHub Copilot app 1.1.25 (Windows); GitHub Copilot CLI 1.0.85 (the SDK-bundled CLI started by copilotd on the remote host); copilotd 0.9.0.
Steps to reproduce the behavior
- In the GitHub Copilot app on Windows, use a remote host backed by a WSL2 distro (copilotd running in the distro).
- Create a worktree session for a GitHub repository on that host.
- Commit a change and push the session branch.
- Ask the agent to open a pull request; it calls
create_pull_request with a title and body.
- The tool returns
Failed to create pull request: runtime settings are not configured for this session.
- On GitHub, the PR exists with the given title and body, and the app shows it linked to the session.
Expected behavior
When the PR is created, create_pull_request reports success with the PR number and URL. If a non-essential step after creation fails, the result should say that the PR was created (partial success, including the PR URL) instead of reporting that creation failed.
Additional context
- OS: Windows desktop app; remote host is a WSL2 distro (Azure Linux 4.0, kernel 6.6.87.2-microsoft-standard-WSL2), x86_64.
- Session: worktree session, executing on the remote (WSL) host.
- The error string does not appear in the copilotd 0.9.0 binary on the remote host, so it appears to come from the desktop app.
- Hypothesis (unverified): a step after PR creation reads per-session runtime settings that are not configured for remote-host sessions, and the tool reports that as a failure to create the PR.
- Not checked: whether this also happens for local (non-remote) sessions.
- No existing issue found for this error message.
Describe the bug
In the GitHub Copilot app, the
create_pull_requestsession tool returns an error for a session running on a remote WSL host, even though the pull request is created successfully:After the error:
get_sessionreportscreated_pr_numberandcreated_pr_state: open, and the session has been renamed to the PR title.So creating and linking the PR both succeed, and the error comes from some later step. This happens consistently in this setup: the user sees it on essentially every PR opened through the tool.
Impact: the agent treats the call as failed. It either stops to ask the user, or falls back to
gh pr create, which then fails witha pull request for branch "<branch>" into branch "main" already exists. Every PR creation costs extra turns and an interruption, and the misleading error invites repeated attempts.Affected version
GitHub Copilot app 1.1.25 (Windows); GitHub Copilot CLI 1.0.85 (the SDK-bundled CLI started by copilotd on the remote host); copilotd 0.9.0.
Steps to reproduce the behavior
create_pull_requestwith a title and body.Failed to create pull request: runtime settings are not configured for this session.Expected behavior
When the PR is created,
create_pull_requestreports success with the PR number and URL. If a non-essential step after creation fails, the result should say that the PR was created (partial success, including the PR URL) instead of reporting that creation failed.Additional context