Skip to content

Native issues

A project in Arugula control can keep issues of its own, beside or instead of a GitHub repository’s. They live on the platform page, and each one has a thread for its comments. GitHub’s issues and pull requests open as blocks instead: see Pull requests and issues.

Issues come with chat: you have them once a team you’re in has chat turned on. Its owners turn it on under Teams… on control’s page.

  • The list: Issues in the platform page’s bar, at app.arugula.io/p/PROJECT/issues. It shows open or closed issues, and narrows by words, Label or Assignee. The project’s home lists its newest open ones.
  • One issue: its title and description, then its timeline (edits, labels, assignees, closing) and its comments in one column, in time order. Its own link, app.arugula.io/issues/iss_…, works anywhere.
  • As a block: arugula open '#12' (or arugula open iss_…) opens it beside your panes. On control’s page it reads and writes as you, and updates live.
  • Export: the list’s Export menu downloads every issue, open and closed, with its timeline and comments, as JSON or Markdown.

A project’s owners and editors open issues, edit them, close and reopen them, and set their labels and assignees. Everyone in the project reads them and comments.

  • New issue on the list (or + New issue on the project’s home) opens one, with labels and assignees.
  • Where new issues go is a project setting, Where new issues go in Project settings: Here, on Arugula, or On GitHub. A project with a linked repo starts with GitHub; then New issue opens GitHub’s form.
  • Assigning someone, or naming them with an @ in the issue or its comments, puts it in their Inbox and notifies them once.

Agent on this, on an open issue, starts an agent session on it, as if you’d written @arugula in its comments. The session runs on one of the project’s Cloud workspaces, not on anyone’s own machine, as you:

  • The issue and its thread are the agent’s first prompt. Each reply in the thread from you or another owner or editor starts its next turn.
  • A card in the thread shows what it’s doing: queued, working, needs input, done or failed, its branch and its last turn. Its questions are answered on the card by any owner or editor.
  • The workspace pushes only the session’s own branch. PR on the card opens a draft of the pull request, which only you send.

It needs a project with a Cloud workspace that has the repository; owners and editors start it. Hand an issue to an agent walks through it.

To work on it on your own machine instead, arugula issue agent '#12' makes a branch in a worktree of the clone you’re in and starts Claude Code (or Codex, --agent codex) there with the issue and its thread as its prompt, with nothing allowed ahead of time.

arugula issue works on the current project’s issues with no block open. It needs arugula login. #12 or 12 is a number in the current project, iss_… any issue you can read.

Terminal window
arugula issue list # open issues, newest first; --label, --assignee me, --state closed
arugula issue show '#12' # its body, timeline and comments
arugula issue new -t "Frobs leak" -b "…" --label bug --assignee me
arugula issue comment '#12' "On it"
arugula issue close '#12' # completed; --reason not_planned or duplicate
arugula issue reopen '#12'
arugula issue edit '#12' --add-label p1
arugula issue export --format md

The current project is --project NAME (or $ARUGULA_PROJECT), else the project this directory’s GitHub repository is linked to, else your personal one. The project’s issue home says whether issue means its own issues or GitHub’s; --native and --github choose. Run by an agent, the CLI reads native issues but doesn’t write them: agents write through MCP, labelled as theirs.

An agent on one of your machines reads and writes a project’s issues with Arugula’s MCP tools:

  • forge_read with kind issue and #N (or iss_…) reads one, its timeline and its newest comments; kind native_issues lists or searches them.
  • issue_write creates, comments on, edits, labels, assigns, closes or reopens one, at once, as your agent on that machine. GitHub’s issues stay drafts that a person sends.

Both need a grant for that machine over the project: threads.read to read, issues.write to create and change, threads.post to comment (arugula grants add laptop issues.write --project acme, or a switch under Agents on your machines in the platform page’s settings). They never go past your own role in the project.