`seaport pr` completely broken with current gh CLI: `--remote` flag rejected when repo argument is provided

[suhailskhan]

Description

Running seaport pr fails with gh ≥ v2.88.0 due to a breaking change in how gh repo fork handles the --remote flag. This renders Seaport unusable unless we manually edit the installed package source (/opt/local/Library/Frameworks/Python.framework/Versions/3.11/lib/python3.11/site-packages/seaport/_pull_request/pull_request.py).

Error

the `--remote` flag is unsupported when a repository argument is provided

This causes the fork/clone to fail, and the subsequent os.chdir in sync_fork then raises FileNotFoundError: [Errno 2] No such file or directory: .../macports-ports.

Root Cause

gh repo fork is called with both a repository argument (macports/macports-ports) and --remote=true (Line 109):

seaport/seaport/_pull_request/pull_request.py

Lines 102 to 112 in 8bb98ae

	subprocess.run(
	[
	f"{user_path(False, True, gh)}/gh",
	"repo",
	"fork",
	"macports/macports-ports",
	"--clone=true",
	"--remote=true",
	],
	check=False,
	)

The --remote flag is only valid when running gh repo fork inside an existing repo (to add a remote for a fork of the current repo). When a repository argument is provided, it is not accepted. This was made an explicit error in cli/cli#12375 (merged 2026-03-02, first included in gh v2.88.0). Notably, prior to v2.88.0 the flag was silently ignored rather than rejected, so seaport was already not behaving as intended, just without a visible error.

With --clone=true, gh already automatically adds the original repo as the upstream remote, so the flag is redundant.

Fix

Remove --remote=true from the gh repo fork call. The upstream remote is set up automatically when --clone=true is used with a repo argument.

Environment

• macOS Sequoia 15.7.5
• gh CLI 2.88.1 (via MacPorts)
• seaport (latest via MacPorts)