一句话概括
MuseAI 在 Linux 上似乎“迷路”了，我不确定是我的系统问题还是什么别的 —— 它找不到 ~/Documents/MuseAI/，我手动给它铺好了路，它却视而不见。最后只能在 Windows 的 Docker 里“借宿”，但代价是电脑风扇狂转，手机访问功能可能也罢工了。😅
预期行为
- 据我猜测，首次启动时，MuseAI 应在
~/Documents/MuseAI/ 下自动创建 articles/、references/、outline/、config/、agent-sessions/ 等子目录。
- 若无该目录，程序应提示明确的错误信息，或至少记录到日志文件。
实际行为
-
AppImage 版本（直接跑）：
- 启动后有界面，但是有点卡，而且会在我点一下设置后卡死，终端仅输出一行 GTK 警告：
** (MuseAI:1001883): WARNING **: 21:02:14.170: atk-bridge: get_device_events_reply: unknown signature
- 程序不退出（需要 Ctrl+C 强制结束），从文件管理器里看也没有创建数据目录。
- 手动创建目录并设置权限后，问题依旧。
-
deb 版本（Distrobox 内的 Ubuntu 22.04 容器）：
- 界面可以启动，但功能无法使用，弹出“导入失败”/“加载文件失败”。
- 同样未能自动创建
~/Documents/MuseAI/。
- 手动创建并
chown 后，仍然报相同的路径错误，仿佛程序完全不信任我铺的路。
-
其他尝试：
- 以
root 权限运行（sudo）—— 无用。
- 设置
XDG_DATA_HOME 环境变量 —— 无用。
- 使用不同版本（0.8.3 和 0.7.8）—— 行为完全一致。
- 解压 AppImage 后运行
./AppRun —— 依然报错。
-
唯一的“成功”：
- 在
winboat的一个Windows10 Docker 容器中运行，程序自动在挂载的 /mnt/Petri/Documents/MuseAI/ 下创建了完整目录，且运行正常。但：
- Windows 容器资源占用高（CPU/内存）。
- 同一 WiFi 下通过浏览器访问”会出问题（直接访问超时了）。
复现步骤
在CachyOS宿主机（AppImage）
cd ~/AppImage
chmod +x MuseAI_0.8.3_amd64.AppImage
./MuseAI_0.8.3_amd64.AppImage
终端输出仅：
** (MuseAI:1001883): WARNING **: 21:02:14.170: atk-bridge: get_device_events_reply: unknown signature
主页会出现，但有点卡，也无数据目录自动在应有的目录里生成。
手动创建目录后再试（依然失败）
mkdir -p ~/Documents/MuseAI/{articles,references,outline,config,agent-sessions}
./MuseAI_0.8.3_amd64.AppImage行为不变，仍然报一样的错误。
环境信息
- 宿主机 OS：CachyOS (内核Linux 7.0.s)
- 显示服务器：Wayland（也试过 X11，同样问题）
- AppImage 版本：0.8.3 和 0.7.8（均从release下载）
- DEB 测试环境：Distrobox 容器（Ubuntu 22.04），
$HOME=/mnt/Vault/Ubuntu
- 工作容器：
winboat (Windows 10 Docker 容器)，可正常运行，但手机可能访问不通。
注：用户 .bashrc / .zshrc 未设置特殊环境变量，$HOME 为默认 /home/cloudycrispy。
附加信息
- 在所有 Linux 尝试中，程序没有生成任何日志文件（如
~/.config/MuseAI/logs 或 ~/Documents/MuseAI/*.log），也无 stderr 输出（除了那行 GTK 警告）。
strace 跟踪显示程序在尝试访问 /home/cloudycrispy/Documents/MuseAI 后，陷入某种等待状态，但未给出错误码。- 相同 AppImage 在 Ubuntu 22.04 原生桌面（非容器）下测试过吗？—— 未测试，但我怀疑与 electron 运行时或文件系统权限检查有关。
建议
呃...我确实没办法获取更多的错误日志，我也不知道咋入手，如果是我系统问题说不定我可以折腾一下，但前提是得知道哪里出问题嘛😿
截图
嗯...大概是这样：
AppImage进入后，任何和作品目录有关的都会报那个错误：
还有，如果点导入，就会有这个错误：
感谢开发者的辛勤付出！如需更多调试信息（如 strace 完整输出或 ldd 依赖检查结果），请随时告知，我非常乐意配合。
一句话概括
预期行为
~/Documents/MuseAI/下自动创建articles/、references/、outline/、config/、agent-sessions/等子目录。实际行为
AppImage 版本（直接跑）：
deb 版本（Distrobox 内的 Ubuntu 22.04 容器）：
~/Documents/MuseAI/。chown后，仍然报相同的路径错误，仿佛程序完全不信任我铺的路。其他尝试：
root权限运行（sudo）—— 无用。XDG_DATA_HOME环境变量 —— 无用。./AppRun—— 依然报错。唯一的“成功”：
winboat的一个Windows10 Docker 容器中运行，程序自动在挂载的/mnt/Petri/Documents/MuseAI/下创建了完整目录，且运行正常。但：复现步骤
在CachyOS宿主机（AppImage）
终端输出仅：
主页会出现，但有点卡，也无数据目录自动在应有的目录里生成。
手动创建目录后再试（依然失败）
mkdir -p ~/Documents/MuseAI/{articles,references,outline,config,agent-sessions} ./MuseAI_0.8.3_amd64.AppImage行为不变，仍然报一样的错误。
环境信息
$HOME=/mnt/Vault/Ubuntuwinboat(Windows 10 Docker 容器)，可正常运行，但手机可能访问不通。附加信息
~/.config/MuseAI/logs或~/Documents/MuseAI/*.log），也无stderr输出（除了那行 GTK 警告）。strace跟踪显示程序在尝试访问/home/cloudycrispy/Documents/MuseAI后，陷入某种等待状态，但未给出错误码。建议
呃...我确实没办法获取更多的错误日志，我也不知道咋入手，如果是我系统问题说不定我可以折腾一下，但前提是得知道哪里出问题嘛😿
截图
嗯...大概是这样：
AppImage进入后，任何和作品目录有关的都会报那个错误：
还有，如果点导入，就会有这个错误：
感谢开发者的辛勤付出！如需更多调试信息（如
strace完整输出或ldd依赖检查结果），请随时告知，我非常乐意配合。