fix(ui): fix resource tag transition from home to task

[TheodoreSpeaks]

Summary

Resource tags were getting lost between home and task pages. This was because:

1. Backend post didn't receive tagged resources and didn't save them
2. Frontend ui didn't optimistically save the tag/item, so the @ symbol wasn't rendering as the resource and the resource tab didn't open until later

Fixed both by persisting tagged resources to initial chat request and optimistically using tag between home and resource page.

Type of Change

• Bug fix
• New feature
• Breaking change
• Documentation
• Other: ___________

Testing

Tested locally, deleting resources, multiple resources, copilot chats.

Checklist

• Code follows project style guidelines
• Self-reviewed my changes
• Tests added/updated and passing
• No new warnings introduced
• I confirm that I have read and agree to the terms outlined in the Contributor License Agreement (CLA)

Screenshots/Videos

[vercel]

The latest updates on your projects. Learn more about Vercel for GitHub.

1 Skipped Deployment

Project	Deployment	Actions	Updated (UTC)
docs	Skipped		Apr 13, 2026 8:00pm

[cursor]

PR Summary

Medium Risk
Medium risk because it changes initial chat creation/persistence on both client and server, which could affect task history hydration and resource panel state for new chats.

Overview
Fixes resource tags getting lost when transitioning from the home page to a newly created task by including current resourceAttachments in the initial chat POST and persisting them server-side for new chats.

On the client, useChat now stores the full PersistedMessage for the pending user message and seeds the new task’s React Query cache with both the initial user message and current resources; removing a resource also clears activeResourceId if needed. On the home page, UserInput now supports onContextRemove to immediately remove resource tags when a context tag is deleted.

^{Reviewed by Cursor Bugbot for commit 907f286. Bugbot is set up for automated code reviews on this repo. Configure here.}

[greptile-apps]

Greptile Summary

This PR fixes two bugs that caused resource tags (added via @ in the home input) to be lost when transitioning from the home to the task page. The backend fix adds a persistChatResources call for newly created chats so tagged resources survive after the stream completes and the chat history refetches. The frontend fix sets resources in the React Query optimistic cache when the new chat ID arrives via SSE, and adds addResource calls in handleContextAdd so the panel opens immediately.

Confidence Score: 5/5

Safe to merge — the primary bug is correctly fixed; remaining findings are P2 quality/token-efficiency concerns.

Both the backend persistence gap and the missing optimistic cache update are addressed cleanly. The two P2 findings (duplicate LLM context for @-tagged resources, missing folder case) are quality improvements rather than correctness blockers.

apps/sim/app/workspace/[workspaceId]/home/home.tsx — duplicate context delivery and missing folder case in resolveResourceFromContext.

Important Files Changed

Filename	Overview
apps/sim/lib/copilot/chat/post.ts	Adds persistChatResources call for new chats when resourceAttachments are present; correctly placed after chat creation and before stream lock acquisition, but introduces a potential duplicate context path for @-tagged resources.
apps/sim/app/workspace/[workspaceId]/home/hooks/use-chat.ts	Adds resources: resourcesRef.current to the optimistic React Query cache update for new chats, ensuring resources are visible immediately when the task route loads during an active stream.
apps/sim/app/workspace/[workspaceId]/home/home.tsx	Adds resolveResourceFromContext helper and wires handleContextAdd to call addResource so @-tagged items appear in the resources panel immediately; missing folder case and introduces potential duplicate context delivery to the LLM.

Sequence Diagram

sequenceDiagram
    participant User
    participant HomeView
    participant useChat
    participant Backend as POST /api/chat
    participant DB

    User->>HomeView: Types @workflow + message
    HomeView->>useChat: handleContextAdd(context)
    useChat->>useChat: addResource({type:'workflow', id}) [NEW]
    Note over useChat: resources state updated

    User->>HomeView: Submit
    HomeView->>useChat: sendMessage(text, [], contexts)
    useChat->>Backend: POST {contexts: [@workflow], resourceAttachments: [workflow]} [BOTH]

    Backend->>DB: resolveOrCreateChat → chatIsNew=true
    Backend->>DB: persistChatResources(chatId, resourceAttachments) [NEW]
    Backend-->>useChat: SSE: session event {chatId}

    useChat->>useChat: queryClient.setQueryData(chatId, {resources: resourcesRef.current}) [NEW]
    useChat->>HomeView: router.replace(/task/chatId)

    HomeView->>useChat: initialChatId changes → applyLoadedChatHistory
    useChat->>useChat: setResources(chatHistory.resources) → panel expands

    Backend->>DB: Stream completes → invalidateChatQueries
    DB-->>useChat: Refetch chatHistory with persisted resources

Loading

Comments Outside Diff (2)

1. apps/sim/app/workspace/[workspaceId]/home/home.tsx, line 288-297 (link)

   Duplicate LLM context for @-tagged resources

   handleContextAdd now calls addResource, so any @-tagged item ends up in both the resources state (serialised as resourceAttachments in the request) and in contexts. The backend's resolveAgentContexts processes both paths independently — processContextsServer for contexts and resolveActiveResourceContext for each entry in resourceAttachments — then concatenates the results. For the same workflow, table, knowledge-base, or file that a user tags with @, the full serialised content is therefore sent to the LLM twice, doubling token cost for that resource on the first message.

   One lightweight fix is to skip the resourceAttachments processing on the server for any resource whose ID already appears in the resolved contexts array, or alternatively to not include resources in resourceAttachments that were added from a context tag rather than from the panel's own history.

2. apps/sim/app/workspace/[workspaceId]/home/home.tsx, line 269-286 (link)

   Missing folder case in resolveResourceFromContext

   ChatContext supports kind === 'folder' (with a folderId field), and MothershipResourceType includes 'folder'. The default branch returns null, so a user who @-tags a folder won't have it added to the resources panel or included in resourceAttachments.

_{Reviews (1): Last reviewed commit: "fix(ui): fix resource tag transition fro..." | Re-trigger Greptile}