fix: use local-assistant ID for /v1/ HTTP routes#5037
Conversation
Co-Authored-By: Claude <noreply@anthropic.com>
There was a problem hiding this comment.
💡 Codex Review
Here are some automated review suggestions for this pull request.
Reviewed commit: 7fac18422f
ℹ️ About Codex in GitHub
Your team has set up Codex to review pull requests in this repo. Reviews are triggered when you
- Open a pull request for review
- Mark a draft as ready
- Comment "@codex review".
If Codex has suggestions, it will comment; otherwise it will react with 👍.
Codex can also answer questions or update the PR. Try commenting "@codex address that feedback".
| const newRouteMatch = path.match(/^\/v1\/(?!assistants\/)(.+)$/); | ||
| if (newRouteMatch) { | ||
| return this.dispatchEndpoint('self', newRouteMatch[1], req, url); | ||
| return this.dispatchEndpoint('local-assistant', newRouteMatch[1], req, url); |
There was a problem hiding this comment.
Keep assistant-less routes compatible with existing
self data
Changing the assistant-less /v1/<endpoint> namespace from self to local-assistant breaks upgrades for any client that previously used these routes, because pre-existing conversation keys and attachments were stored under assistant_id='self' and downstream lookups require an exact assistantId match. After this change, those users will get empty message histories and 404 attachment fetches until they explicitly switch to legacy /v1/assistants/self/... endpoints, so this should include a migration or fallback read path to preserve existing data.
Useful? React with 👍 / 👎.
Summary
/v1/<endpoint>HTTP routes passed'self'as the assistantId, but all IPC-created data (attachments, conversations) is stored withassistant_id = 'local-assistant'/v1/attachments/:idto return 404, breaking lazy-load video playback'local-assistant'directly, matching the canonical ID used by the daemon session🤖 Generated with Claude Code