Using the workspace
Integrations
Connect source control, issue trackers, Sentry, notifications and self-hosted CI runners. Credentials stay on your computer and never reach a model.
Settings → Apps & connectors is the one place you connect Duscode to everything Dus can use (see Apps and connectors). For the services around your code: Source control, Issues, Errors, Notifications and CI runners. Each row says what connecting it lets Dus do, its status, and where its credential is kept.
- Credentials stay on your computer. GitHub and GitLab use your own command-line login; Duscode stores no token for them. Everything else is kept in your vault, encrypted, and masked anywhere it could appear.
- Nothing is sent to a model. Dus works with these services through Duscode, never by seeing a token.
- Status is honest: Connected as octo, Not connected, or gh not installed with the fix.
Source control
| Service | How it connects | What it lets Dus do |
|---|---|---|
| GitHub | Your GitHub CLI login: run gh auth login once |
Select repository, pull requests from Git, create a new project's repository |
| GitLab | Your GitLab CLI login: run glab auth login once |
Your projects in the repository list, merge requests from Git |
| Bitbucket Cloud | Your Atlassian email and an API token, saved to the vault as BITBUCKET_API_TOKEN |
Your repositories in the repository list, pull requests from Git |
When a session's origin is on GitLab, the button in Git reads Open merge request. On Bitbucket it opens a pull request through Bitbucket's API. Either way the branch is pushed with your own git credentials and never forced.
Bitbucket API token: create one in your Atlassian account settings (Security → API tokens) with permission to read repositories and write pull requests. App passwords are no longer accepted by Bitbucket.
Not yet: Bitbucket Server and Data Center, GitLab and Bitbucket issues, and pipelines.
Disconnecting
Disconnect deletes what Duscode stored for that service: the vault entry and its settings. For GitHub and GitLab, Duscode stores nothing; sign out with gh auth logout or glab auth logout.
Issues: start from an issue
Connect a tracker, then click + in the message box and choose Start from an issue. You see the open issues assigned to you from every connected tracker, newest first; type to search by key, title, repository or team.
| Tracker | How it connects |
|---|---|
| GitHub Issues | Your GitHub CLI login (nothing more to set up) |
| Linear | A personal API key (Linear → Settings → Security & access), saved to the vault as LINEAR_API_KEY |
| Jira Cloud | Your site (your-team.atlassian.net), your Atlassian email and an API token, saved to the vault as JIRA_API_TOKEN |
Picking an issue starts a new session in its own worktree. Its first message is the issue's title, description and link, and Dus works on it right away. Dus treats the issue's text as a description of the work written by other people: it never changes Dus's rules, permissions or budget, and anything risky still asks you first.
When the work is done and the checks pass, Dus prepares the pull request. Its description references the issue:
| Tracker | In the pull request | What happens on merge |
|---|---|---|
| GitHub | Closes #12 (or Closes owner/repo#12 for another repository) |
GitHub closes the issue |
| Linear | Fixes ENG-123 |
Linear moves the issue, if Linear's GitHub or GitLab integration is installed |
| Jira | The key first in the title, and a link | Jira links it, if Jira's GitHub, GitLab or Bitbucket app is installed. Jira doesn't close issues from pull requests. |
After you open the pull request from Git, Duscode asks whether to comment the link on the issue. The comment holds the link and nothing else, and it is only posted if you say yes.
Errors: fix a Sentry issue
Connect Sentry with your organization slug and a personal auth token (User settings → Personal Tokens, with org:read, project:read and event:read). The token is saved to the vault as SENTRY_AUTH_TOKEN. For de.sentry.io or a self-hosted Sentry, also give its address.
Then click + and choose Fix a Sentry issue. Pick the project; you see its unresolved issues with how often each happened and when it was last seen. Picking one starts a Fix a bug session in its own worktree, from the issue's latest event: its stack trace with the source lines around each frame, and its breadcrumbs.
Personal data and secrets are removed first, on your computer, before Dus sees anything:
- Removed whole: the user (id, email, username, IP), the request's headers, cookies, body and query string, local variables in stack frames, breadcrumb data, device and app context, extra data and tags other than environment, release, browser, OS, runtime, transaction and URL.
- Replaced in everything kept: email addresses, IP addresses, tokens (JWTs, bearer tokens, API keys), passwords in URLs, secret query parameters, card-like numbers, phone numbers, private keys and any value in your vault.
The session's first message lists what was removed, and Dus reproduces the bug with made-up data.
Notifications
Hear about Dus's work without watching the tab. Each channel has its own switches for three events:
- A scheduled job needs you or failed (scheduled jobs)
- A long task finished while you were away: a task that ran 2 minutes or more, when no Duscode tab has been in view for a minute
- A deploy finished or failed
| Channel | How it connects |
|---|---|
| Desktop notifications | Turn on, then allow notifications when your browser asks. Shown while any Duscode tab is open, even in the background; clicking one opens the session. |
| Slack | An incoming webhook URL for the channel (Slack app → Incoming Webhooks), saved to the vault as SLACK_WEBHOOK_URL |
| Microsoft Teams | A webhook URL from the channel's Workflows ("Post to a channel when a webhook request is received"), saved to the vault as TEAMS_WEBHOOK_URL |
Send test posts one message so you can see it arrive. If a webhook stops working, its row says so.
What a message contains: the project, the session's title, what happened ("Scheduled job needs you", "Deploy to production failed") and a link that opens the session in Duscode on your computer. Never code, command output, diffs or secrets.
Not available: replying to Dus from Slack or Teams. That would need a hosted relay between your workspace and your computer, and Duscode doesn't route your work through the cloud.
CI runners
Run this project's GitHub Actions on your own machine: a server you deploy to, or this computer. Self-hosted runners don't use GitHub's hosted minutes, so CI keeps running even when hosted minutes run out.
Settings → Apps & connectors → CI runners shows the project's self-hosted runners (online or offline, busy, labels, and where Duscode installed them) and how long recent jobs waited for a runner. It uses your GitHub CLI login, which needs admin rights on the repository.
- Set up a runner starts a session with the Set up a self-hosted runner skill. Dus asks where (a server you already deploy to over SSH, or this computer), which labels, and whether each job should get a clean runner (ephemeral). It then downloads GitHub's official runner, registers it, installs it as a service under a normal user (never root), and checks that GitHub lists it online. Installing always asks you first. Finally it offers to change
runs-on:in your workflows, as an edit you review. - Check my runners looks at each runner's status, queue time, disk, memory, work folder, caches and last log lines, and suggests fixes: clean the work folder, enable caching, add a runner, or switch to ephemeral runners. Nothing changes until you pick the fixes.
- Logs, Restart and Remove on a runner each start a session. Removing always asks you first.
The short-lived token that registers a runner is fetched through your GitHub CLI when it is needed and passed straight to the install. It is never stored, never shown, and never sent to a model.
Not yet: GitLab runners, organization-wide runners, Windows machines.