Bug: Qoder ignores Windows Documents folder redirection and creates workspace in hardcoded C:\Users\<username>\Documents path

Bug Reports
1

Environment

  • OS: Windows 11 25H2 (Build 26200)
  • Qoder: Latest version

Description

When the Windows “Documents” folder is redirected to a custom path (e.g., D:\System\Documents) via the standard Windows folder properties dialog, Qoder still creates its workspace directory at the hardcoded default path C:\Users\<username>\Documents\Qoder\ instead of respecting the redirected path.

Steps to Reproduce

  1. Redirect the Windows Documents folder to a custom path (e.g., D:\System\Documents) via File Explorer > Documents > Properties > Location > Move
  2. Verify the registry HKCU\Software\Microsoft\Windows\CurrentVersion\Explorer\Shell Folders\Personal correctly shows the redirected path
  3. Open Qoder and start a new chat session
  4. Observe that Qoder creates workspace at C:\Users\<username>\Documents\Qoder\ instead of D:\System\Documents\Qoder\

Expected Behavior

Qoder should use the Windows Shell Folders API (or equivalent) to resolve the actual Documents path, respecting user-configured folder redirection.

Actual Behavior

Qoder appears to construct the path by concatenating C:\Users\<username>\Documents directly, bypassing the system’s folder redirection configuration. This results in:

  • Unwanted directories created on the C: drive
  • Workspace data not being stored in the user’s intended location

Registry Verification

HKCU\...\Shell Folders\Personal = D:\System\Documents  (correct)
C:\Users\skyler\Documents = exists as physical directory (not a symlink)
D:\System\Documents\Qoder = does not exist

Suggested Fix

Use SHGetKnownFolderPath(FOLDERID_Documents) or Environment.GetFolderPath(Environment.SpecialFolder.MyDocuments) in .NET to resolve the Documents path at runtime, instead of hardcoding C:\Users\<username>\Documents.

2 Likes