Jupiter Workspaces

Turn GitHub Issues, optional Jira tasks, Sentry bugs, and local custom tasks into isolated VS Code workspaces with task branches, AI context, pull requests, and GitHub Actions in one flow.

Jupiter is built for engineers who live in VS Code and need task-scoped worktrees. Pick a GitHub issue, a Jira task when Jira is configured, or create a local custom task, then Jupiter creates a dedicated git worktree, keeps every task in its own branch and workspace, and opens the right context when it is time to code, review, run CI, or create a pull request.

Why Teams Use Jupiter

GitHub Issues provide the default task queue. Jira can be added when the project uses it. Local custom tasks cover ad hoc work that has no external issue yet. Jupiter prepares the local workspace where that work can happen safely.

• Start several GitHub issues, Jira tasks, or local custom tasks without constantly switching one checkout back and forth.
• Keep each task in its own git worktree, branch, VS Code workspace, and saved session.
• Preserve SSH or HTTPS remotes from the source repository.
• Create a per-task agent context for OpenAI Codex IDE, OpenAI Codex CLI, or VS Code Chat / GitHub Copilot.
• Give Codex live task, worktree, GitHub, Jira, Confluence, Sentry, Actions, and Telegram context through the managed Jupiter MCP server.
• Link several Telegram project forums and mirror task, Global Agent, or allowed Codex sessions into durable topics.
• Review changed files, generate concise commit messages, commit, push, and open GitHub pull requests from the task view.
• Run and track selected GitHub Actions workflows for the task branch.
• Prepare and approve a human-readable QAA test strategy against a successful deployment of the exact task SHA, then generate bot routes, run them, and copy confirmed bug cards.
• Diagnose GitHub task access, optional Jira access, Git, remotes, and workspace configuration from one command.

Daily Workflow

1. Run Jupiter: Setup Wizard once for the repository.
2. Open the Jupiter Activity Bar view and refresh GitHub tasks.
3. Open the permanent Local Task for direct work on the main checkout, start a sourced task from the tree, or run Jupiter: Create Custom Task for isolated ad hoc work.
4. Jupiter creates or reuses a task branch and opens an isolated worktree workspace.
5. Use Jupiter: Create Agent when you want a task-aware Codex IDE, Codex CLI, or Copilot agent.
6. Inspect task files, commit and push, run the selected task Action, and create a pull request.
7. Jupiter links Jira PRs back to Jira when the task came from Jira, and keeps every task session available until you remove it.

Screenshots

Tasks In VS Code

Group active sessions, GitHub issues, and configured Jira tasks by work state, filter the list, create local custom tasks, and start work without leaving the editor.

Task Details And Local State

See the branch, worktree path, PR state, Git notices, task Action state, and the next available task actions in one view.

Task-Aware Agent Context

Create a per-task agent with generated .jupiter/agent-context.md and .jupiter/codex-agent-prompt.md files, so Codex IDE, Codex CLI, or Copilot starts with the GitHub, Jira, or local custom task, branch, repository, and worktree context.

Core Features

• Task worktrees: create one local git worktree per GitHub issue, Jira task, or local custom task, under a configurable worktree root.
• Local custom tasks: start ad hoc work from a title, optional description, and a key like LOCAL-1 when no external issue exists yet.
• Permanent Local Task: open one full Jupiter task directly on the configured base branch in the main checkout, with agent, Telegram, Git Files, Actions, and QAA support but no issue, predefined goal, branch creation, worktree, or PR flow.
• Branch naming: generate stable task branch names from task keys and summaries. GitHub issues use canonical keys like GH-123; local custom tasks default to LOCAL-N.
• Workspace profiles: save and switch named Jupiter configuration profiles for different repositories or teams.
• Agent handoff: create or reopen task agents through OpenAI Codex IDE, run headless Codex CLI agents, or use VS Code Chat / GitHub Copilot.
• Global Agent: create one reusable project-wide Codex thread in the main checkout and reopen it from any Jupiter task window without moving it into a task worktree.
• Jupiter MCP: connect Codex to the running Jupiter extension through a local authenticated bridge. Read tools use current Jupiter state; repository and external-system actions require approval in Jupiter.
• Sentry bugs: discover every project accessible to a Sentry token, optionally filter projects and event tags, incrementally update issues, display total event counts, and preserve a capped logarithmic sample of stack traces for task agents.
• Telegram session bridge: run one persistent local host for several Jupiter projects and Telegram forums, with Codex history import, native typing status, approvals, stop, crash recovery, and provider-neutral task topics.
• Task files: inspect branch and working tree changes, open editable diffs, and focus on the files that matter for the current task.
• Commit and push: use a Jupiter Git Files view with an editable suggested commit message and in-view Commit & Push control.
• Pull requests: push the task branch, create a GitHub PR, and write the PR link back to Jira only for Jira-sourced tasks.
• GitHub Actions: choose a workflow, dispatch it for the task branch, and track the latest run status from the task detail view.
• QAA: after a successful deployment of the current SHA, Jupiter analyzes the task and optional complementary client/server repository, presents a concise test strategy for explicit approval, then generates 20–100 source-grounded route sheets and starts the bots immediately. Completed runs expose only reproduction-backed bug cards for copying; nothing is sent to a task agent.
• Diagnostics: verify GitHub sign-in, optional Jira credentials, git remotes, source paths, worktree root, and base branch setup.

Requirements

• VS Code 1.120 or newer.
• Git available in PATH.
• GitHub sign-in in VS Code with repository access.
• Jira Cloud email and API token only when the project uses Jira tasks.
• Optional read-only Sentry token with org:read, project:read, and event:read when the project uses Sentry bugs.
• Optional Telegram bot token and one or more Telegram supergroups with Topics enabled.
• OpenAI Codex extension/CLI for the default task-agent and stable App Server bridge flow, or GitHub Copilot Chat for the alternative IDE-only agent flow.
• A GitHub repository configured through Jupiter: Setup Wizard or detected from the current workspace origin remote.

Setup

1. Install Jupiter Workspaces.
2. Open the repository Jupiter should use as the base checkout for task worktrees.
3. Run Jupiter: Setup Wizard.
4. Enter the GitHub repository, base branch, local repo for task worktrees, worktree root, PR mode, and AI settings, then select the GitHub account for this project.
5. Choose Configure Jira now or Skip Jira for now. Skipping Jira leaves any existing Jira settings and secrets untouched.
6. Open the Jupiter Activity Bar view and run Refresh GitHub Tasks.
7. Start a GitHub issue from the tree or with Jupiter: Start Task. Jira tasks appear after jupiter.jira.baseUrl and Jira credentials are configured. Use Jupiter: Create Custom Task when the work has no GitHub or Jira issue.

Jupiter writes shared non-secret settings to the current VS Code workspace, not User Settings. Local project state, including Telegram enablement and the selected GitHub account ID and label, is stored in the Git-excluded .jupiter/state.json; every GitHub API call requests that exact VS Code account instead of using the extension's global session preference. Use Jupiter: Select GitHub Account to switch only the current project. Jira credentials stay in VS Code SecretStorage when Jira is configured.

Run Jupiter: Configure Sentry, enter the read-only token, and select one organization. Organization selection is required; until it is set, Sentry remains not configured and does not synchronize bugs. Jupiter uses every project in the selected organization by default. Jupiter: Change Sentry Organization switches the workspace to another accessible organization and resets project filters and cached Sentry sync state. Jupiter: Configure Sentry Filters can optionally restrict projects or events by tags such as environment=production; an empty filter means all projects in the selected organization or all events. The first refresh imports issues with events from the previous 7 days; subsequent refreshes incrementally add or update one Jupiter bug per Sentry issue. Tokens remain in VS Code SecretStorage and are never returned through MCP.

After setup, Jupiter registers a global Codex MCP server named jupiter. The MCP process never receives provider tokens: it calls the running extension, which continues to own VS Code SecretStorage and GitHub authentication. Use Jupiter: MCP Status, Jupiter: Connect Codex MCP, or Jupiter: Disconnect Codex MCP to manage the connection.

Marketplace releases are platform-specific so the installed extension includes the correct system-keychain binary for macOS, Windows, Linux, or Alpine. If Codex is not available during setup, Jupiter keeps the project setup complete and offers Retry MCP Setup after Codex is installed.

For Telegram, create a supergroup, enable Topics, and add the Jupiter bot as an admin with permission to send messages and manage topics. The Setup Wizard reuses a bot token already stored for Jupiter: it offers the verified bot name/id or Enter a new bot token, without displaying the secret. You can also open Jupiter: Show Workspace Dashboard and select the Telegram tab. Before a token exists, the tab deliberately shows only Configure Telegram Bot. After Telegram verifies it, Jupiter shows the bot username/id and verification time with Replace Bot Token, then reveals the ordered Enable Bridge and Pair First Forum steps. Pair First Forum immediately generates and copies a one-time /jupiter pair CODE command; it does not ask for a forum ID or link. Step 3 keeps that command visible with Copy Again, Generate New Code, and Cancel Request until Telegram accepts it, it is cancelled/replaced, or it expires. A replacement immediately invalidates the previous pending command. If VS Code Reloads, Jupiter restores the pending request metadata without storing the plaintext command and offers Generate Replacement or Cancel Request. Send the command in any topic of the forum you want to pair. The incoming Telegram update supplies the exact Bot API chat.id, so no preliminary message, invite link, or manual ID lookup is needed. Once pairing succeeds, Jupiter offers Choose Tasks… and keeps a visible Active task topics step with an exact per-forum ready count. The selector opens with every active task checked, but synchronization starts only after confirmation. Jupiter creates or reuses topics for the selected tasks and imports recent history for tasks that already have a Codex thread. Every operation leaves a visible result; Show Jupiter Logs is available under the advanced tools. Replacement is validated before storage, so cancelling or entering an invalid token keeps the previous token. The same actions remain available from the Command Palette. The first user to pair in each forum becomes that forum's owner. The legacy Jupiter: Link Telegram Project route remains available for existing task topics. See the full bridge guide for roles, background services, approvals, recovery, and security boundaries.

Each paired forum in the Dashboard also has Remove Pairing for the current project. Removal detaches only this project's bindings: Telegram topics, Codex threads, mirror cursors, and imported history are preserved. A forum shared with other Jupiter projects keeps those projects and its users/roles. Removing its last project clears the forum authorization and roles, so a later connection must be paired again. Stop any active Telegram turn in that forum before removing the pairing.

Run Jupiter: Run Diagnostics if tasks do not load, worktree creation fails, GitHub actions are missing, or a PR cannot be created.

Release work is represented by a dedicated Jupiter release session. Create Release starts from a Jira release task whose parent is a Story, asks for the version, and creates release/<PARENT-STORY>-v<version> (for example, release/CCG-26826-v1.36). Move Task to Release rebases an ordinary task onto an active release and nests it below the highlighted release block in Active Tasks. A release can contain multiple deployment Action cards. Each deploy runs from the release branch, prompts for the workflow's workflow_dispatch inputs (including a GitHub environment or stage choice), and shows the deployed stage on its card.

Commands

• Jupiter: Setup Wizard: configure GitHub, the local repo used for task worktrees, worktree root, PR mode, AI settings, and optional Jira.
• Jupiter: Select GitHub Account: choose and validate the VS Code GitHub account used only by the current Jupiter project.
• Jupiter: Show Workspace Dashboard: inspect active task source, Git, GitHub, optional Jira, and workspace profile settings.
• Jupiter: Save Workspace Profile / Jupiter: Switch Workspace Profile: manage named jupiter.* setting groups.
• Jupiter: Refresh Tasks: reload all available task sources and active task sessions.
• Jupiter: Refresh GitHub Tasks: reload GitHub issues from the configured repository.
• Jupiter: Refresh Jira Tasks: reload Jira tasks when Jira is configured.
• Jupiter: Configure Sentry: save a read-only auth token and select the required organization for this workspace.
• Jupiter: Change Sentry Organization: switch to another organization accessible to the saved token.
• Jupiter: Configure Sentry Filters: optionally select projects in the chosen organization and add key=value event-tag filters.
• Jupiter: Refresh Sentry Bugs: incrementally synchronize Sentry issues and representative stack samples.
• Jupiter: Start Task: use or create a task branch and isolated git worktree.
• Jupiter: Start Subtask: choose a started parent task and create a fresh task branch from its current local branch.
• Jupiter: Create Release: create a release session from a Jira release task, using its parent Story ID and the entered version for the release branch.
• Jupiter: Move Task to Release: rebase an ordinary task onto an active release branch and record that release as its parent.
• Jupiter: Create Custom Task: create a local Jupiter task and start its isolated branch and worktree.
• Jupiter: Open Local Task: open the permanent issue-free task in the main checkout on the configured base branch without creating a branch, worktree, or VS Code workspace.
• Jupiter: Start Task With Branch: choose an existing branch or enter a custom branch name.
• Jupiter: Start Task From Branch: create a fresh task branch from a selected base branch.
• Jupiter: Open Worktree: open the task worktree in the current VS Code window.
• Jupiter: Open Task in Fork: open the exact task worktree in Fork's Commit view to inspect its local changes and diff.
• Jupiter: Change Task Branch: move an active task session to another existing branch, switching the task worktree when it is clean or linking an already checked-out worktree.
• Jupiter: Create Agent: create a per-task Codex or Copilot agent with generated Jupiter context files.
• Jupiter: Open Agent: reopen the configured agent surface for a task that already has an agent.
• Jupiter: Open Global Agent: create the project-wide Codex agent in the configured base-branch checkout, or reopen its saved thread when it already exists.
• Jupiter: Show Task Files: inspect files changed by the task branch and working tree.
• Jupiter: Commit & Push Task: commit selected task changes and push the task branch.
• Jupiter: Open Task Source Control: open the task worktree and focus Source Control, or Jupiter Git Files when VS Code Git is disabled.
• Jupiter: Select Task Action: choose the GitHub Actions workflow used for the task branch.
• Jupiter: Run Task Action: push the task branch and dispatch the selected GitHub Actions workflow.
• Jupiter: Refresh Task Action Status: refresh the latest tracked task Action run.
• Jupiter: Restore Recommended QAA Defaults: restore Sol/Terra/Luna role routing and a 100-base-bot ceiling.
• Jupiter: Create Pull Request: push the task branch, create a GitHub PR, and link it to Jira only for Jira tasks.
• Jupiter: Configure Telegram Bot: save and verify a Telegram bot token in VS Code SecretStorage.
• Jupiter: Enable Telegram Bridge / Jupiter: Disable Telegram Bridge: install or remove only Jupiter's background-service registration while preserving bindings and history.
• Jupiter: Show Telegram Pairing Code: create a one-time, bot-bound pairing command that expires after 10 minutes; send it in the target forum so Telegram supplies the forum ID automatically.
• Jupiter: Cancel Pending Telegram Pairing: revoke an unfinished one-time pairing command without changing any established forum pairing.
• Jupiter: Remove Telegram Forum Pairing: detach the selected forum from only the current project while preserving its Telegram topics, Codex threads, and mirrored history.
• Jupiter: Synchronize Active Tasks to Telegram: create or reuse one topic per active task, restore detached bindings after re-pairing, safely recreate manually deleted topics, and import Codex history where available.
• Jupiter: Resolve Ambiguous Telegram Delivery: explicitly assume or retry a history chunk, attachment, header send, or header pin whose Telegram outcome could not be proven after a crash. The bridge never retries these operations automatically because Bot API sends have no caller idempotency key.
• Jupiter: Link Telegram Project: bind the current project to a Telegram supergroup/forum.
• Jupiter: Create Telegram Topic For Task: create and link a Telegram forum topic for an active task.
• Jupiter: Send Telegram Task Update: send the current task state to its Telegram topic.
• Jupiter: Open Telegram Topic / Jupiter: Unlink Telegram Topic: manage the task's Telegram topic binding.
• Jupiter: Cancel Task: remove the task from Jupiter's active list without changing the source task, local worktree, or local branch.
• Jupiter: Open Task Source: open the source issue in GitHub, Jira, or Sentry. Local custom tasks show that no external source URL exists.
• Jupiter: Run Diagnostics: check GitHub auth, optional Jira, Git, settings, and workspace remote setup.
• Jupiter: MCP Status: inspect the managed Codex MCP registration and local bridge.
• Jupiter: Connect Codex MCP / Jupiter: Disconnect Codex MCP: manage the global jupiter MCP registration.
• Jupiter: Rotate MCP Bridge Token: rotate the local bridge credential in the system keychain.

Active task sessions, the active task marker, the Global Agent conversation ID, Telegram enablement, and saved workspace profiles are stored per project in .jupiter/state.json. Jupiter adds that file to the repository's local .git/info/exclude when possible, so the state stays on the machine without polluting commits. Generated Jupiter task workspaces inherit the same project state path, so task windows still see their source task and Global Agent while unrelated project folders stay isolated.

Settings

• jupiter.ai.agentProvider: Agent surface Jupiter opens for per-task agents. Use codex for the OpenAI Codex IDE extension, codexCli for a headless Codex CLI agent, or copilotChat for VS Code Chat / GitHub Copilot. The persistent Telegram bridge is provider-neutral: it mirrors allowed Codex threads through the stable App Server API, polls history for turns created by an independent IDE process, and reports CLI fallback as degraded.
• jupiter.ai.codexOpenTarget: Where the Codex Global Agent opens. Task agents always open in the existing Codex sidebar of the current VS Code window; Jupiter passes the task worktree as the thread cwd without opening another window.
• jupiter.ai.gitAgentModel: Codex CLI model used only for automated merge and rebase operations such as Rebase and Upbase. Defaults to gpt-5.6-sol.
• jupiter.ai.gitAgentReasoningEffort: Reasoning effort for automated merge and rebase operations. Defaults to high; ordinary task-agent conversations are unaffected.
• jupiter.ai.userLanguage: Language for Jupiter's user-facing UI, notifications, and locally rendered reports. auto follows the VS Code display language; en and ru select English or Russian explicitly. The setting is not added to agent prompts and does not constrain the agent's conversation language.
• jupiter.ai.utilityAgentModel: Lightweight Codex CLI model for branch names and commit summaries. Defaults to gpt-5.6-luna.
• jupiter.ai.utilityAgentReasoningEffort: Reasoning effort for lightweight utility requests. Defaults to low.
• jupiter.jira.baseUrl: Optional Jira Cloud base URL.
• jupiter.jira.jql: JQL used to load task list.
• jupiter.jira.maxResults: Maximum Jira tasks to load across enhanced JQL search pages.
• jupiter.sentry.enabled: Enable incremental Sentry bug synchronization.
• jupiter.sentry.organizationSlug: Required Sentry organization selected for this workspace.
• jupiter.sentry.baseUrl: Sentry Cloud or self-hosted base URL.
• jupiter.sentry.projectFilters: Optional organization/project filters; empty includes every project in the selected organization.
• jupiter.sentry.tagFilters: Optional key=value event-tag filters; empty includes all events. Repeat a key for OR and use different keys for AND.
• jupiter.github.owner: GitHub owner or organization.
• jupiter.github.repo: GitHub repository name.
• jupiter.github.baseBranch: Base branch for worktrees and PRs.
• jupiter.github.draftPr: Create PRs as draft by default.
• jupiter.github.issueQuery: GitHub issue search query. Jupiter automatically adds repo:owner/repo.
• jupiter.qaa.plannerModel, jupiter.qaa.minimizerModel, and jupiter.qaa.analystModel: Codex models for contract-aware planning, repro reduction, triage, and confirmed bug cards. Recommended default: gpt-5.6-sol.
• jupiter.qaa.baseBotModel: Codex model used by every base Quality Assistant. Recommended default: gpt-5.6-terra.
• jupiter.qaa.candidateModel and jupiter.qaa.confirmationModel: Codex models used for minimized candidate checks and the ten final confirmations. Recommended default: gpt-5.6-luna.
• jupiter.qaa.maxBots: maximum base bots and simultaneous Codex processes within one task run; minimum 20, recommended default 100. Repro jobs share the same queue but do not count toward the base total.
• jupiter.qaa.statefulActors, jupiter.qaa.targetedBots, jupiter.qaa.actorDurationSeconds, jupiter.qaa.rampBatchSize, and jupiter.qaa.rampIntervalSeconds: workload profile. Defaults are 15 client-like actors, 5 targeted bots, five-minute sessions, and a ramp of 3 bots every 2 seconds.
• QAA is built into Jupiter and stores its plans, run state, sanitized observations, reproductions, bug cards, and family-scoped contract memory under .jupiter/qaa/. Knowledge proposed by the Analysis Agent affects future plans only after manual approval; source changes make approved entries stale. QAA reasoning effort inherits jupiter.ai.gitAgentReasoningEffort.
• Detailed route sheets are not generated before approval. Changing the task SHA, stage, repositories, roles, source manifests, workload, models, or approved Contract Memory invalidates the strategy and requires a new review.
• Completed QAA v2 runs expose confirmed bug cards for copying. Jupiter never attaches QAA output to a task agent. Runs from schema v1 remain read-only history and are not re-analyzed or migrated.
• jupiter.git.branchPrefix: Branch prefix, default feature.
• jupiter.git.disableVsCodeGitInWorktrees: Disable built-in VS Code Git in generated task worktree workspaces, preventing automatic Git scans. Enabled by default.
• jupiter.git.remoteUrl: Optional SSH/HTTPS git remote URL used for source clones.
• jupiter.git.sshKeyPath: Optional SSH private key path used for Git clone, fetch, and push operations.
• jupiter.git.sourcePath: Optional local checkout Jupiter uses as the base when creating task worktrees. Leave empty to let Jupiter clone the configured GitHub repository automatically.
• jupiter.git.worktreeRoot: Folder where task worktrees are created. The setup wizard offers the project-local .jupiter/workspaces folder as the recommended option and excludes it locally through .git/info/exclude.
• jupiter.mcp.enabled: Start the local Jupiter MCP bridge and keep its managed Codex registration current after setup. Enabled by default.
• jupiter.pr.titleTemplate: PR title template.
• jupiter.pr.bodyTemplate: PR body template.
• Telegram enablement is local Jupiter project state managed from the Dashboard; it is not written to .vscode/settings.json.
• jupiter.telegram.autoCreateTopics: Automatically create a Telegram topic when Jupiter sends the first Telegram update for a task.

jupiter.telegram.sessionBridge.* is shared by every Jupiter window because one singleton host serves all registered projects. The local-runtime controls enabled, backgroundMode, and codexTransport are machine-scoped so Settings Sync cannot apply another machine's daemon or executable policy; the remaining bridge preferences are application-scoped. On first enable, an existing valid host configuration is migrated and retained until an explicit global setting overrides it.

• jupiter.telegram.sessionBridge.enabled: Enable the persistent Codex session bridge.
• jupiter.telegram.sessionBridge.sessionScope: List only registered project sessions (default) or all sessions inside allowed canonical roots.
• jupiter.telegram.sessionBridge.autoCreateSessionTopics: Automatically create arbitrary session topics; disabled by default.
• jupiter.telegram.sessionBridge.historyTurns: Number of completed turns imported initially; default 20.
• jupiter.telegram.sessionBridge.syncIntervalSeconds: IDE-created history polling interval; default 30 seconds.
• jupiter.telegram.sessionBridge.approvalMode: Answer stable approvals in Telegram (default) or continue them in VS Code.
• jupiter.telegram.sessionBridge.codexTransport: Stable App Server with CLI fallback (default), App Server only, or degraded CLI only. CLI fallback turns are always read-only with approvals disabled.
• jupiter.telegram.sessionBridge.backgroundMode: OS-login service (default) or extension-lifetime host.

Telegram Commands

Inside a bound session topic, send a normal message to continue the same Codex thread. Your Telegram message remains under your real account and Jupiter replies to it as the bot; the history mirror never reposts it as a misleading You bubble. While Codex works, Jupiter uses Telegram's native forum-topic typing… status instead of posting queue, elapsed-time, command, or completion messages; only the actual Codex answer is sent as a reply. Codex IDE does not expose a public thread-invalidation command, so after a Telegram turn Jupiter reloads existing webviews in place and lets Codex read the persisted history again. The reload does not navigate, reveal, or focus VS Code. Prompts discovered in IDE history are clearly labelled Imported from Codex / IDE, while assistant replies and safe command summaries have separate visual roles. File-change items and local paths are not mirrored automatically; request project details explicitly with /jupiter files, /jupiter diff, or /jupiter update. Repeated App Server messages are deduplicated only within the same turn. Turns created in the IDE are mirrored by periodic stable history reads. Jupiter accepts:

• /jupiter pair CODE
• /jupiter projects
• /jupiter tasks [--project ID] [--page N] [--summary]
• /jupiter sessions [--project ID] [--page N]
• /jupiter sync
• /jupiter history [count]
• /jupiter status
• /jupiter summary
• /jupiter files
• /jupiter diff
• /jupiter action
• /jupiter pr
• /jupiter update
• /jupiter stop
• /jupiter detach
• /jupiter archive
• /jupiter reopen
• /jupiter users
• /jupiter diagnostics
• /jupiter help

Owner/operator/viewer permissions are scoped independently per forum. Owners manage numeric user IDs and roles; operators start/stop turns and answer approvals; viewers read status, history, files, and diagnostics. Add a task key, such as /jupiter status GH-123, for legacy task addressing.

Troubleshooting

Run Jupiter: Run Diagnostics first. It prints a structured report to the Jupiter output channel with the configured version, GitHub repository, GitHub issue query, optional Jira URL, Telegram status, JQL limit, git remote URL, base branch, source path, worktree root, Git availability, Jira credential check, GitHub sign-in state, and detected workspace origin.

If GitHub tasks do not load, run Jupiter: Select GitHub Account, then verify jupiter.github.owner, jupiter.github.repo, jupiter.github.issueQuery, and repository access for that project account. If Jira tasks do not load, verify that jupiter.jira.baseUrl points to your Jira Cloud tenant and that the saved API token belongs to the same Atlassian account.

If worktree creation fails, verify local Git authentication for the configured remote URL. Jupiter preserves SSH remotes when it detects them, so your normal SSH key setup should continue to work.

Known Limitations

• Jupiter currently targets GitHub Issues for the primary task queue, Jira Cloud for optional Jira task queues, local custom tasks for ad hoc work, Telegram supergroup forum topics for task updates, and GitHub pull requests.
• Telegram group creation is not automated; Jupiter uses user-created supergroups with Topics enabled. The local machine must remain powered on and online because no public webhook/cloud relay is installed.
• IDE-created turns are mirrored by polling/history reads; only Telegram-created turns have the bridge's live event stream.
• Some Jira transition automation and multi-repository workflows are still evolving.