kimi-web: @ file mention shows no matches in the initial prompt of a new conversation

[ifsheldon]

What issue are you seeing?

In the kimi-web frontend, when drafting the initial prompt of a new conversation in a workspace (before any message has been sent), typing @ to mention a file always shows "No matches", no matter the query. After the first message is sent and the conversation exists, @ file mention works correctly.

What steps can reproduce the bug?

1. Open a workspace in kimi-web.
2. Start a new conversation (the empty draft state with no conversation history).
3. In the composer, type @ followed by the name of a file that exists in the workspace.
4. The mention menu opens but always shows "No matches".
5. Send any message, then type @ again — file search now returns matches as expected.

What is the expected behavior?

@ file search should return matching files from the workspace while drafting the initial prompt, before the first message is sent.

Additional information: diagnosis

The @ search is keyed off the active session, and a new-conversation draft deliberately has no session, so the search short-circuits to empty before ever reaching the server:

• apps/kimi-web/src/composables/client/useWorkspaceState.ts — searchFiles() returns [] immediately when rawState.activeSessionId is undefined.
• Entering the new-conversation draft state (openWorkspaceDraft) calls clearActiveSession(). Per the comment there, this is by design: "No backend session is created until the user sends the first message" — the session is only created lazily by createDraftSession on the first send.
• The daemon endpoint is strictly session-scoped: POST /sessions/{sid}/fs:search (apps/kimi-web/src/api/daemon/client.ts), resolved server-side from the session's ISessionFsService (packages/kap-server/src/routes/fs.ts). There is no workspace-scoped or cwd-scoped search endpoint the frontend could call while no session exists.
• The mention menu itself is wired correctly: the searchFiles prop is always passed down (App.vue → ConversationPane → ChatDock → Composer), so on the draft screen the menu opens and then renders its empty state. It looks like "no files match", but the search never actually ran.

Reproduced on current main (c497af60).

[Sparkle6979]

Thanks for the detailed write-up. I took a quick look at this path, and I think the behavior is clear, but the fix is a small design choice.

The shortest fix seems to be creating the draft session when file mention search runs without an active session, then reusing /sessions/{sid}/fs:search. That would keep the patch small, but it also means typing a file mention like @foo in the empty composer creates a persistent session before the first message is sent.

A cleaner alternative might be a workspace-scoped search path for the draft state, so the composer can search files before a session exists while preserving the current lazy session creation behavior.

I would lean toward the workspace-scoped search, but wanted to check what direction maintainers prefer before putting up a PR. If that approach sounds reasonable, I would be happy to send a fix.