* fix(daemon): enforce runtime ownership on daemon routes (MUL-8154)
/api/daemon/* accepts any workspace member's PAT/JWT, and authorization only
checked workspace membership. Any member could claim another member's tasks
(receiving the agent's custom_env, MCP config and an owner-scoped task token),
write task results/messages, and take a runtime over by re-registering its
daemon_id.
- Runtime-level check on every runtime/task daemon route, HTTP heartbeat,
deregister, batch claim (and so the WS claim RPC) and the WS handshake:
user credentials must own the runtime (NULL owner fails closed); daemon
tokens must match a non-empty runtime daemon_id.
- Register: pre-check that every existing row on the daemon_id belongs to the
caller, plus a required_owner_id fence in both upserts (incl. the
failed-profile path) so a concurrent registration cannot win the row.
Daemon-token registration keeps the existing owner.
- Legacy merge: only for user-credential registrations, and only when the
caller owns both rows, verified on the FOR UPDATE-locked rows.
- Tasks without a runtime are not writable through daemon routes; status
stays readable.
- GetTaskStatus / WS lease queries carry runtime owner/daemon so the hot
paths keep one round trip.
Co-authored-by: multica-agent <[email protected]>
* test(daemon): authenticate fixtures as the runtime owner (MUL-8154)
Most handler tests drove daemon routes with a daemon token whose daemon_id
did not match the fixture runtime, relying on the workspace-wide token scope
this fix removes. They now authenticate the way real daemons do, with the
runtime owner's user credential (newOwnerDaemonRequest). Tests about daemon
token scoping keep mdt_ and get fixtures with a matching daemon_id; the
ownerless-runtime tests also assert that a user credential is refused.
Co-authored-by: multica-agent <[email protected]>
* fix(daemon): serialize registration per daemon and keep Qoder WS claims working (MUL-8154)
Review of #9423:
- P1: the owner pre-check and the per-provider/profile upserts hit different
conflict keys, so two members registering different providers of the same
daemon could both pass the pre-check and both insert, leaving one daemon
with two owners (and a daemon token for either runtime reaching the
other's). Registration now runs the pre-check and every runtime write in one
transaction under a pg_advisory_xact_lock on (workspace_id, daemon_id), on a
single connection so queued registrations cannot starve the holder. Legacy
merges, analytics and the register event run after commit; failed-profile
records use savepoints so they stay best-effort.
- P2: the Qoder revocation check read the Authorization header, which the WS
RPC bridge's in-process request does not carry, so valid Qoder WS claims
silently returned nothing. DaemonAuth now records the mdt_ token hash in the
request context, the WS identity keeps it, the RPC bridge re-attaches it,
and the check validates that hash on every call (revocation still applies
to an open connection).
- Regression tests for cross-provider and provider+profile concurrent
registration, and for valid/revoked Qoder credentials over WS RPC.
Co-authored-by: multica-agent <[email protected]>
* fix(daemon): bind daemon tokens to the runtime owner they were issued for (MUL-8154)
Second review of #9423: a daemon_id can be re-registered by another member
after its runtimes are deleted, and a daemon token was bound only to
(workspace, daemon_id), so the previous owner's Remote MCP token reached the
new owner's runtime (heartbeat, claim, owner-scoped task token).
- daemon_token.owner_id (migration 588). Remote MCP tokens are bound to the
locked runtime owner inside FinalizeTaskClaim; live tokens are backfilled
only where their daemon has exactly one owner.
- DaemonAuth carries the owner binding (DB and cache; cache key bumped to v2
so pre-upgrade entries are never read), the WS identity keeps it and the
RPC bridge replays it.
- Daemon-token authorization now also requires token owner == runtime owner.
Qoder-managed tokens stay unbound (governed by cloud_agent_connection), and
user credentials can no longer register the reserved qoder-managed-* ids.
- Tests: the reuse lifecycle over HTTP, a new WS handshake and an already
open WS connection; the reserved daemon_id; the concurrency barrier now
hooks the registration transaction (TxStarter) so the interleaving is real.
Co-authored-by: multica-agent <[email protected]>
* fix(daemon): owner-bind daemon-token registration; drop unsafe token backfill (MUL-8154)
Third review of #9423:
- Migration 588 no longer backfills daemon_token.owner_id from the daemon's
current owner: that owner may be a later re-registrant, which re-bound the
previous owner's live token to them. Existing non-Qoder tokens stay NULL and
are refused (24h Remote MCP credentials, re-issued on the next claim).
- owner_id is a plain UUID column, no foreign key / cascade (AGENTS.md).
- Register via a non-Qoder daemon token now uses the token's owner for the
in-transaction pre-check and the SQL owner fence, and refuses unbound
tokens. Qoder keeps its connection-based check; daemon tokens still never
trigger legacy merges.
- Tests: an old owner's bound token and an unbound legacy token can neither
register over nor heartbeat the replacement owner's runtime.
Co-authored-by: multica-agent <[email protected]>
* fix(daemon): grant the Qoder registration exemption only with a live connection (MUL-8154)
Fourth review of #9423: register skipped the token owner binding for any
qoder-managed-* daemon token, but checked the Qoder connection only when the
body declared a qoder_cloud runtime. A pre-upgrade Remote MCP token under that
prefix (no owner, no connection) could register type=claude and rewrite
another member's runtime.
Register now verifies the token against a live cloud_agent_connection before
anything else whenever the token is in the Qoder namespace, regardless of the
declared runtimes, and restricts that namespace to the bridge's own shape: a
built-in qoder_cloud runtime, no custom profiles, no failed_profiles.
Test covers built-in, custom-profile, failed-profiles-only and qoder_cloud
bodies with an unconnected token, plus the connected token's allowed and
refused shapes.
Co-authored-by: multica-agent <[email protected]>
---------
Co-authored-by: multica-eve <[email protected]>
Co-authored-by: multica-agent <[email protected]>
- Add migration 106: CREATE INDEX CONCURRENTLY on member(user_id, workspace_id)
- Rewrite ListWorkspaces to drive from member table with explicit fields
- Regenerate all sqlc code with v1.31.1 (intentional version upgrade)
Co-authored-by: multica-agent <[email protected]>
* feat(workspace): revoke a member's runtimes when they leave or are removed
Previously, leaving or being removed from a workspace only deleted the
member row — every runtime the departed user owned in that workspace
remained in the DB, kept its daemon_token valid, and stayed reachable to
the workspace's other members. The departed user lost access but their
machine kept doing work.
This change converges the runtime state in the same transaction as the
member-row deletion: agents pinned to those runtimes are archived,
in-flight tasks are cancelled (so the daemon's per-task status poller
interrupts the running agent gracefully), the runtimes are forced
offline, and the daemon_token rows are deleted. After commit the
DaemonTokenCache is invalidated and agent:archived / daemon:register
events fire so connected clients reconcile immediately.
Server-side state convergence is the production safety net; the
daemon_token revoke takes effect once the mdt_ flow is live (today most
daemons fall back to PAT/JWT, and the member-row deletion is what stops
those requests via requireWorkspaceMember).
Daemon-side handling (recognising the resulting 401/404 and tearing down
the local pairing for that workspace) lands in a follow-up.
Co-authored-by: multica-agent <[email protected]>
* fix(workspace): also cancel tasks for archived agents on member revoke
CancelAgentTasksByRuntime only matched tasks whose runtime_id was in the
revoked set, missing a real path: agent.runtime_id can be reassigned via
UpdateAgent, but agent_task_queue.runtime_id keeps the value from when
the task was queued. So an agent currently bound to the leaving member's
runtime gets archived correctly, but its older tasks still pinned to a
prior runtime stay 'queued' — and ClaimAgentTask does not gate on
agent.archived_at, so those orphaned tasks remain claimable by the
prior runtime.
Replace CancelAgentTasksByRuntime with CancelAgentTasksByRuntimeOrAgent,
which OR-matches runtime_ids and the archived agent IDs in one UPDATE.
Pass the archived agent IDs through from revokeAndRemoveMember.
Adds TestDeleteMember_CancelsTasksFromAgentReassignment as a regression
guard: same agent, two runtimes, the older task on the surviving runtime
must end up cancelled while the surviving runtime stays online.
Co-authored-by: multica-agent <[email protected]>
---------
Co-authored-by: multica-agent <[email protected]>
Users can now mute specific notification categories (assignments, status
changes, comments & mentions, priority/due-date updates, agent activity)
from Settings > Notifications. Muted event types are silently filtered at
notification creation time — no inbox items are created for muted groups.
- Add notification_preference table (migration 064)
- Add GET/PUT /api/notification-preferences endpoints
- Filter notifications in notifyIssueSubscribers, notifyDirect, and
notifyMentionedMembers based on user preferences
- Add Notifications tab in Settings with per-group toggle switches
Issue daemon auth tokens (mdt_) on pairing session claim, bound to
workspace_id + daemon_id with 1-year expiry. Add DaemonAuth middleware
that validates these tokens and falls back to JWT/PAT for backward
compatibility. Apply middleware to all daemon routes except pairing
endpoints.
