Bug description
When a workspace directory is deleted after sessions have been created in it, the web UI handles the missing directory poorly in two places.
1. @-mention search shows "no match" instead of the real error
Reproduction steps
- Create a session in a directory (e.g.
/private/tmp/kimi-test-cwd).
- Delete that directory from outside the app.
- Return to the session in Kimi Code Web and type
@package in the composer.
Expected behavior
The mention menu should show the backend error, e.g. ENOENT: no such file or directory, realpath '/private/tmp/kimi-test-cwd'.
Actual behavior
The menu shows "无匹配" (no match), hiding the fact that the workspace directory is gone.
Root cause
workspaceState.searchFiles() in apps/kimi-web/src/composables/client/useWorkspaceState.ts catches fs:search failures and returns an empty array.
2. New sessions can still be created in the deleted directory
Reproduction steps
- Delete the workspace directory of an existing workspace.
- In the sidebar, click the "+" next to that workspace (or use the onboarding composer in the empty workspace).
- Send any message.
Expected behavior
No new session should be created; the UI should surface the error and explain that the directory no longer exists.
Actual behavior
A new session is created with a cwd pointing to the deleted directory, and the first prompt is submitted.
Root cause
createSessionInWorkspace() and startSessionAndSendPrompt() in useWorkspaceState.ts call api.createSession() without verifying that cwdForCreate still exists. Only the NewSessionDialog path validated the cwd.
Suggested fix
- Make
searchFiles() propagate errors so the composer can render an error state.
- Add a shared
validateCwdForCreate() helper that calls browseFs() before every session-creation path.
- Ensure
browseFs() itself propagates errors (the folder picker already has a defensive wrapper).
Environment
- Kimi Code Web (
apps/kimi-web)
- Browser: any
Bug description
When a workspace directory is deleted after sessions have been created in it, the web UI handles the missing directory poorly in two places.
1. @-mention search shows "no match" instead of the real error
Reproduction steps
/private/tmp/kimi-test-cwd).@packagein the composer.Expected behavior
The mention menu should show the backend error, e.g.
ENOENT: no such file or directory, realpath '/private/tmp/kimi-test-cwd'.Actual behavior
The menu shows "无匹配" (no match), hiding the fact that the workspace directory is gone.
Root cause
workspaceState.searchFiles()inapps/kimi-web/src/composables/client/useWorkspaceState.tscatchesfs:searchfailures and returns an empty array.2. New sessions can still be created in the deleted directory
Reproduction steps
Expected behavior
No new session should be created; the UI should surface the error and explain that the directory no longer exists.
Actual behavior
A new session is created with a cwd pointing to the deleted directory, and the first prompt is submitted.
Root cause
createSessionInWorkspace()andstartSessionAndSendPrompt()inuseWorkspaceState.tscallapi.createSession()without verifying thatcwdForCreatestill exists. Only theNewSessionDialogpath validated the cwd.Suggested fix
searchFiles()propagate errors so the composer can render an error state.validateCwdForCreate()helper that callsbrowseFs()before every session-creation path.browseFs()itself propagates errors (the folder picker already has a defensive wrapper).Environment
apps/kimi-web)