Make codex://new?originUrl handle GitHub repo, issue, and PR onboarding
TL;DR
When codex://new?originUrl=... receives a GitHub URL that does not match an existing local workspace, Codex should do the reasonable app-level thing: prompt to create/select an environment, start cloning or fetching the repo, and open a thread seeded with the GitHub repo/issue/PR context.
The strongest ask is to extend the existing documented originUrl flow instead of requiring users to manually copy a URL, find or create the project in Codex, and craft the prompt by hand.
This likely implies two small product capabilities:
- A dialog for unmatched
originUrlvalues: choose clone location/environment, reuse existing checkout if detected, or cancel. - A first-run setup state where Codex can start outside a fully ready workspace, show clone/setup progress, and let the user interact while the repo is still becoming available.
Feature request
I want a fast path from GitHub into Codex Desktop for repository exploration, OSS maintainer workflows, and contribution workflows.
The ideal flow would let me open a GitHub repository, issue, or pull request in Codex directly from GitHub or from the Codex app. Codex would create or select an environment, start cloning or fetching in the background, preserve the GitHub context, and let me interact immediately while setup continues.
Use case
A common workflow for me is exploring an OSS library and asking questions like:
- Does this library support this feature or approach?
- Is this bug I hit already known?
- Is this likely easy to fix?
- Where in the codebase is this behavior implemented?
- Can we build a quick repro or harness?
It is also useful for general OSS maintainer work. When I am looking at issues and PRs on GitHub, the natural next step is often to investigate or act on that item in Codex:
- inspect an issue against the local source
- check whether a reported bug is valid
- reproduce a failure
- find the owning code path
- review a PR locally
- run tests
- continue work from a PR branch
- draft a maintainer response with source-backed evidence
Today that handoff is awkward: copy the GitHub URL, open or find the project in Codex, craft a prompt, paste the context, and then wait for Codex to rediscover what I was looking at.
The powerful part of Codex is local codebase intelligence: fast grep, source navigation, tests, examples, and custom repro harnesses. The missing piece is making GitHub-to-Codex handoff feel immediate.
Desired behavior
When opening a GitHub repo, issue, or PR through codex://new?originUrl=..., Codex should:
- If the URL matches an existing local workspace, keep today's behavior.
- If the repo is not local yet, show a confirmation dialog with clone/environment options.
- Create or select a local environment for the repository.
- Start cloning/fetching the repository in the background.
- Open a thread immediately with setup progress visible.
- Let me interact with Codex while setup is still running.
- Preserve the GitHub context that launched the workflow.
- Once enough code is available, use local search, grep, tests, examples, and project tooling to answer deeper questions.
- Avoid creating duplicate projects for the same repo unless I explicitly choose a new checkout.
Example links:
codex://new?originUrl=https%3A%2F%2Fgithub.com%2Fowner%2Frepo
codex://new?originUrl=https%3A%2F%2Fgithub.com%2Fowner%2Frepo%2Fissues%2F123
codex://new?originUrl=https%3A%2F%2Fgithub.com%2Fowner%2Frepo%2Fpull%2F456
Issue and PR-specific behavior
If originUrl is a GitHub issue URL, Codex should:
- normalize to the repo remote
- attach the issue URL/title/body metadata to the starting context
- search the local codebase for relevant implementation details
- help determine whether the request is already supported
- help reproduce the issue when possible
- make it easy to draft a source-backed maintainer response
- optionally create a branch/change for investigating the issue
If originUrl is a GitHub PR URL, Codex should:
- normalize to the repo remote
- fetch the PR branch/ref
- inspect the diff locally
- run relevant tests or a repro harness
- review the change against the source
- make it easy to draft review feedback or a maintainer response
- optionally continue work from the PR branch if permissions and remotes allow it
Optional alternative: codex://repo?...
Extending codex://new?originUrl=... seems like the smallest improvement because originUrl is already the documented bridge from a Git remote URL to a workspace.
That said, a first-class repo link could also be a clean long-term shape if this is considered broader than starting a new thread:
codex://repo?url=https%3A%2F%2Fgithub.com%2Fowner%2Frepo
codex://repo?url=https%3A%2F%2Fgithub.com%2Fowner%2Frepo%2Fissues%2F123
codex://repo?url=https%3A%2F%2Fgithub.com%2Fowner%2Frepo%2Fpull%2F456
A codex://repo link could own repo/environment setup first, then open the appropriate thread, issue investigation flow, review flow, or PR checkout flow.
Related existing pieces
Codex already documents codex://new?<query> and originUrl=<git-remote-url>, where originUrl matches an existing workspace root by Git remote URL.
The current documented behavior does not appear to cover a GitHub repo, issue, or PR URL that can create/select an environment, clone/fetch in the background, and open an interactive Codex workflow around that GitHub context.