[Mrdifferent2022]

What

Makes CopilotKit Intelligence replaceable for self-hosted deployments via the runtime's own AgentRunner seam, so OpenMuse runs fully keyless with threads on its own database:

• THREADS_BACKEND=intelligence|local (default intelligence). The default path is byte-for-byte unchanged; an explicit intelligence selection without a key still fails loudly at startup — never a silent downgrade.
• PersistentAgentRunner (apps/server/src/threads/local-runner.ts) subclasses the runtime's public InMemoryAgentRunner: it hydrates threads from the database before run/connect, so history survives API restarts.
• Durability boundary: the terminal RUN_FINISHED event is held until the snapshot write completes, and a failed write surfaces as a visible RUN_ERROR instead of a silent loss (the blocker flagged on feat: run chat fully offline with CopilotKit Intelligence optional #94).
• Owner-scoped, database-backed thread listing via an app-layer route (the runtime's built-in local fallback is process-global and cannot scope by owner).
• Rename/archive/realtime metadata remain Intelligence-only; the native UI hides them in local mode rather than faking them (direct calls get the runtime's own 422).
• The demo harness follows the same setting and runs keyless.

Builds on #94 (same seam, same motivation) and addresses the review feedback left there on 2026-10-06: awaited persistence with visible failure, runner regression coverage (including delayed/failed writes followed by a restart), operator documentation, and a rebase onto current main. Fixes #73.

Test plan

• tests/threads-provider.test.ts (7): RUN_FINISHED held behind a delayed Store.put; failed write → visible RUN_ERROR with nothing saved; history replayed by a fresh runner after ɵGLOBAL_STORE.clear() (restart survival); per-owner scoping; durable clearThreads; provider selection matrix; runtime version pinned against the store contract.
• tests/local-threads.test.ts (5): boots with no CPK_INTELLIGENCE_API_KEY and zero Intelligence contact; main-thread provisioning; owner-scoped pagination; honest 422s for rename/archive; approvals flow unchanged.
• Full suite: 498 tests, 0 failures — existing intelligence-default suites pass unmodified.
• Docs: docs/PLUGGABLE-THREADS.md (config matrix, capability matrix, operator notes); README and .env.example updated.

[jerelvelarde]

I reproduced local-mode blockers on b2711a3 through the actual runtime HTTP path and targeted runner regressions. Keeping changes requested until these are resolved:

• New side chats must persist through the runtime's agent-cloning path, with restart coverage.
• Owner isolation and destructive thread operations need hardening before this backend is safe to merge. I'm keeping the detailed security reproduction out of the public thread.
• Failed runs and concurrent sends must terminate cleanly, and completion must remain behind the durable write.
• In-memory history eviction must not truncate the persisted conversation.

I have a local fix and regression coverage in progress. @matthewhand @Mrdifferent2022, let's agree whether #94 or #166 should carry the final implementation so we can consolidate the work and preserve both contributions. Neither PR needs to be closed while that is being settled.

[Mrdifferent2022]

All four blockers are addressed in 03d2933, with the root causes confirmed in the runtime sources:

• Side chats / cloning: cloneAgentForRequest hands the runner a .clone() of the factory agent, so the owner WeakMap (keyed on the original instance) could not resolve the owner and persist() threw for any thread without a prior record — side chats exactly. ConversationAgent now exposes its owner (clone() preserves it) and the lookup reads it; regression test drives run() with a clone.
• Owner isolation / destructive ops: the runtime's local messages/events/state/clear fallbacks are process-global. Local mode now serves the detail endpoints owner-scoped from the database (other owners get 404, indistinguishable from missing) and POST /threads/clear deletes only the authenticated owner's durable rows; memory is cleared whole since other owners rehydrate from the database.
• Failed/concurrent runs: a run ending without RUN_FINISHED (internal failure — finalizeRunEvents only appends RUN_ERROR) previously held complete forever; the gate now best-effort persists and always closes the stream. A concurrent run() throws synchronously (Thread already running) and is delivered as an observable error, not a hang.
• Eviction truncation: persistence now merges runs by runId into the stored record instead of overwriting with the (possibly evicted) in-memory historicRuns, and v1 thread-level events records migrate on read.

New regressions cover each point, and I verified the full flow over real HTTP: main chat + brand-new side chat persist, a second app instance over the same database replays both after "restart", detail endpoints are owner-scoped, and clear stays owner-local. Full suite: 503 tests, 0 failures.

On #94 vs #166: I'm happy for #166 to carry the final implementation — it currently has the broader surface (owner-scoped endpoints, mobile capability hiding, demo support, operator docs), and I'd gladly take @matthewhand's commits or co-authorship here. If you'd rather consolidate into #94 or your own branch, say the word and I'll port. If your in-progress local fix covers any of these differently, happy to align — the reproduction notes you kept private would help confirm we hit the same paths.

[Mrdifferent2022]

Three follow-up commits since the blocker fixes, all from testing the backend against a real model (Moonshot/Kimi via an OpenAI-compatible gateway):

4153fc8 — full thread-management parity with Intelligence

• Rename / archive / restore / delete now work owner-scoped in local mode (previously Intelligence-only 422s, hidden in the UI). Implemented at the app layer — the SSE runtime itself is untouched — so the native client drives both backends through the identical useThreads mutations.
• Untitled threads get a short title generated by the server's configured MODEL (mirroring generateThreadNames), falling back to a truncated first user message when no model is configured or the call fails. Naming is fire-and-forget after the run persists: it never delays RUN_FINISHED, never overwrites an existing title, and a transient failure self-heals on the next persist.
• The capability matrix in docs/PLUGGABLE-THREADS.md is updated; the only remaining Intelligence-only capability is realtime thread-metadata subscription.

8c127d8 + 4ff990f — fixes found in end-to-end testing

• Mutations never left the client. The SDK gates renameThread/archiveThread/deleteThread on threadEndpoints.mutations from GET /info, which the SSE runtime hardcodes to false for non-Intelligence runtimes — so the app-layer endpoints added above were never called. Local mode now intercepts /api/copilotkit/info and advertises mutations: true (realtime metadata stays off). This is why the endpoints live at the app layer rather than inside the runtime: the capability bit can be corrected without touching SDK internals.
• Title generation against Kimi. The summarize activity maps maxLength to provider-native token keys across several adapter layers, and kimi-k3 only accepts temperature: 1 while spending ~200 reasoning tokens before the summary text — so titles always failed and degraded. OpenAI-compatible providers (Moonshot included) now get titles through a direct chat-completions request with explicit temperature/max_tokens; anthropic/google keep the summarize activity. Any failure still degrades to the truncated first-message title, never a chat error.
• UI rows match the Intelligence layout: title line plus Rename / Archive|Restore / Delete buttons (delete in danger style), one-line ellipsis-clipped titles.

Regression coverage: /info capability bits, titling (generated / preserved / failed), deleteThread, and owner isolation on all management endpoints. Full suite: 510 tests, 0 failures. The Intelligence path remains byte-for-byte unchanged.

[caspianchan31]

Reading the persistence layer as someone who shipped the same architecture in a fork (***/openmuse-standalone, I'm the dev — Alpha, so take this as field notes, not authority): the run-merge, memory-eviction and per-owner clear handling here covers the same corners I had to get right.

One boundary worth making explicit before merge. Inside PersistentAgentRunner the unit of isolation is the bare threadId: hydrate() returns early whenever ɵGLOBAL_STORE.peek(threadId) already exists, without an owner check, and the findRecord() cache-miss path scans every owner's chat-threads rows to resolve an id. The HTTP layer closes this today — every /threads route authenticates ownerFromRequest(req) and compares record.owner === owner before reaching the runner — so I do not see a live cross-tenant hole in the current routes.

The risk is that it only holds if every future caller remembers to authorize first. A later internal entry point (an admin/debug tool, a background job, a webhook replay) that calls runner.run/connect with just a threadId would hydrate and append onto another owner's thread, and the fallback scan would resolve the id across owners anyway.

Two cheap options, in case they fit: key the runner's index/caches by (owner, threadId) and thread owner through hydrate/persist so a mismatch refuses; or leave the runtime store global but make findRecord take the expected owner and reject a row owned by someone else. Single-user sample mode stays on local-user, so nothing changes there; it just moves the invariant from "every caller must check" into the persistence boundary itself. Happy to be wrong if the runtime already namespaces per request — I'm reading against @copilotkit/runtime 1.70.1's process-global store.

[Mrdifferent2022]

Good catch — addressed in 2fcdea9 (branch is also rebased onto current main, so the merge conflict is gone).

You were right that the invariant only held while every caller remembered to authorize first. It now lives at the persistence boundary:

• findRecord takes an expectedOwner and resolves a record owned by someone else to null, on both the cache-hit path and the cross-owner database scan.
• run() passes the agent's owner into hydrate, and both hydrate and persist refuse with Thread not found when the durable record belongs to another owner — a warm in-memory entry no longer skips the check, and a foreign threadId can never be appended to.

One boundary I could not move down, for the record: the runtime's AgentRunnerConnectRequest carries only a threadId (no agent), so connect has no owner to check against — replay authorization stays at the route layer, which was already owner-scoped. Regression tests cover the warm in-memory foreign threadId and a cold-start cross-owner run; full suite is 549 tests, 0 failures.

[Mrdifferent2022]

@jerelvelarde — following up on the consolidation question from your first review, since both branches have now sat for a while.

Where things stand:

• feat: pluggable thread persistence with THREADS_BACKEND=local #166 (this PR): all four blockers from your review fixed in 4b81ae3, rebased onto current main, MERGEABLE with green CI. It has since grown to full thread-management parity with Intelligence (rename / archive / restore / delete, model-generated titles with a truncation fallback) plus the persistence-boundary owner isolation from caspianchan31's review. Backed by 549 passing tests including the runtime-level regression cases.
• feat: run chat fully offline with CopilotKit Intelligence optional #94 (@matthewhand): still a single commit from 2026-10-07, now DIRTY against main, with the original review items (await persistence, regression tests, operator docs) not yet addressed in the public branch.

My suggestion, to keep both contributions intact: let #166 carry the final implementation — it already contains the hardening you asked for on both PRs — and credit #94 as the originating design in the commit message and docs. If you'd rather consolidate the other way, I'm happy to port the parity work over to a PR against @matthewhand's branch instead; just say which shape you prefer and I'll do the legwork.

No urgency if you're mid-review elsewhere — mainly want to make sure this isn't waiting on a decision I can unblock.