How can I get rid of the Issues named "You are running as a local coding agent for a Multica workspace."

[alexrm1x]

Hello,

Everytime I place a request (issue) in Multica, the system creates a "duplicate" issue titled "You are running as a local coding agent for a Multica workspace.". I understand that this is neccesary for the system to work, but, how can I hide those requests in the views or avoid the system to use a TID-XXX numering when creating? Thanks.

[ADanMan]

"You are running as a local coding agent for a Multica workspace." is not an issue title Multica ever generates — it's the fixed opening line of the task prompt the daemon hands to the local coding-agent CLI. It appears at three call sites in server/internal/daemon/prompt.go: the normal assignment ("ownership") prompt (line 96), the comment-reply prompt (line 223), and the autopilot run-only prompt (line 512). I grepped the full repo (non-test .go/.ts/.tsx/.md/.mdx) for this exact string and it only shows up in that file — no server code path ever passes it as an Issue title.

multica issue create requires an explicit --title flag (server/cmd/multica/cmd_issue.go:460); nothing defaults it. So the only way an Issue ends up literally titled with that sentence is that the local coding-agent process itself — the CLI the daemon spawned for the assignment — called multica issue create --title "You are running as a local coding agent for a Multica workspace.", i.e. it echoed the first line of its own received instructions back as a new issue instead of following them (the prompt tells it to run multica issue get <id> --output json first — same file, lines 106/288/537). That's local-agent/runtime behavior on your machine, not something the product intentionally does. To confirm which task and which agent runtime is doing it, check multica daemon logs (server/cmd/multica/cmd_daemon.go:66-70) around the time you file a request, and check which coding-agent CLI/provider is configured for the assignee — a runtime that isn't actually executing multica issue get (auth/config problem, or a provider not well-tuned to the instructions) is the likely cause.

Note Multica already has duplicate-title protection: creating a second active issue with the same normalized title in the same workspace/project/parent is blocked by default ("Active duplicate issue exists...", server/internal/issueguard/duplicate.go:16-42) unless --allow-duplicate/allow_duplicate=true is passed (cmd_issue.go:474,1129; handler/issue.go:2397,2615, both default false). So if you're seeing a new one of these every time, either the earlier one isn't "active" anymore (done/cancelled) or it's landing in a different project/parent scope each time.

On your two actual questions:

1. Getting rid of one: there's no "hide" or "archive" state — valid issue statuses are only backlog/todo/in_progress/in_review/done/blocked/cancelled (handler/issue.go:78, matching the original schema in server/migrations/001_init.up.sql). Delete is the only removal path: open the bogus issue, use its "..." actions menu → Delete (wired through openDeleteConfirm in packages/views/issues/actions/use-issue-actions.ts:186-195, which opens the issue-delete-confirm modal registered in packages/views/modals/registry.tsx:38). That calls DELETE /api/issues/{id} → Handler.DeleteIssue (server/cmd/server/router.go:1103, server/internal/handler/issue.go:3158-3191), which hard-deletes the row, cancels any running/queued task on it, fails linked autopilot runs, and cleans up attachments.

2. Avoiding the TID-XXX numbering: not possible after the fact. Each workspace has a monotonic issue_counter (added in server/migrations/020_issue_number.up.sql) incremented via IncrementIssueCounter (issue_counter = issue_counter + 1, server/pkg/db/generated/workspace.sql.go:255-265) at creation time; the displayed identifier is fmt.Sprintf("%s-%d", issuePrefix, issue.Number) (e.g. issueguard/duplicate.go:38) — exactly your "TID-XXX" pattern. There's no decrement/reclaim query anywhere in the generated SQL, so deleting the bogus issue does not free its number back — the gap is permanent by design, the same as GitHub/Linear-style monotonic issue numbers. The only real fix is stopping the spurious creation at the source (fix/reconfigure the local agent runtime so it actually follows the assignment prompt instead of creating an issue from it).