anomalyco / anomalyco/opencode
[FEATURE]: Persistent first-class work context for GitHub issues/PRs and git worktrees
@jlongster is already working on this.
Since Aug 13, 2026.
- Dominant language
- TypeScript
- Stars
- 209k
- Forks
- 27.5k
- PR merge metrics
- PR metrics pending
Description
Feature hasn't been suggested before.
- I have verified this feature I'm about to request hasn't been suggested before.
Describe the enhancement you want to request
Summary
I want a persistent, first-class work context model that binds a session to a canonical GitHub Issue or Pull Request and automatically tracks the repository, branch, commit, and git worktree the session is operating in. Today the agent must repeatedly rediscover this information (issue number, PR, branch, worktree) on every turn, which causes ambiguity, wasted tool calls, and context bloat.
Motivation
I often describe a task in a GitHub Issue and then have the agent execute it locally. PRs are also first-class interaction targets (review, diff, comments, CI). The same work happens across multiple git worktrees for parallel branches. Today each session starts without any explicit knowledge of:
- Which GitHub Issue or PR is the source of truth for the current task
- Which repository/branch/commit is checked out
- Which git worktree the session is running in
The result is that the agent spends context budget rediscovering these facts, can act on the wrong issue/PR when several are open in the same repo, and loses the connection between the session and its task whenever a session is resumed or compacted.
Desired behavior
- A session can be bound to a canonical GitHub resource (e.g.
@github:org/repo#123for an issue,@github:org/repo!456for a PR). - OpenCode automatically infers and displays the current repository, branch, commit, and worktree for the session.
- The work context persists across session resume and compaction.
- The UI (TUI/Desktop) shows the active work context so the user and agent always agree on what the session is working on.
- Explicit actions to attach, switch, refresh, and clear the context.
- GitHub Issue/PR content is treated as untrusted data by default; mutating actions (comments, push, merge, branch creation) require user confirmation.
Suggested MVP
- Session-level canonical resource binding: store one Issue or PR reference per session.
- Automatic git context: repository, branch, commit, worktree derived from the session's working directory.
- Context visibility: show the current Issue/PR/branch/worktree in the session UI.
- Explicit attach/switch/refresh/clear commands.
- Persistence of the binding across resume and compaction.
Why this is not a duplicate of existing requests
The worktree and context pieces are already partially covered by separate issues, but the integration into one persistent session-level work context is not:
- #34918 — API-managed durable per-session context entries (the storage primitive this would build on)
- #36048 — worktree-based workspace switching with stash-based warp
- #17856 — Git branch indicator in the prompt input
- #34387 — V2
@-tagged file/folder references in prompts - #5409 — SessionStart hook for session lifecycle events
- #28695 — Session lifecycle context hooks for persistent plugin state
- #38842 — Desktop cannot open git worktree folders via "Open Project"
- #36301 — Git Changes panel is not worktree-aware
There is currently no existing issue for a unified, persistent session work-context that binds a canonical GitHub Issue/PR together with git branch/worktree state and surfaces it in the UI.
Notes on extension points
- Plugins can read
directoryandworktreebut there is no stable generic extension point for custom@resource resolution today. - The official GitHub MCP server exposes Issue/PR/branch/CI tools, but worktree management is outside its scope and the agent must still actively call tools to discover context.
- The recommended path is to first add a first-class work-context API at the core level, then optionally expose an
@github:...syntax on top of it.
Contributor guide
First steps
- Read the whole issue, then the project's contributing guide.
- Comment on the issue to say you are picking it up — it saves two people doing the same work.
- Fork the repository and make your change on a branch.
- Open a pull request that references the issue number.
Assessment
This issue has not been assessed yet.