[Bug]: @-mention autocomplete never suggests any file or directory whose name starts with a dot

[pollylol]

Before you submit

• I searched existing issues and confirmed this is not a duplicate.
• I replaced the example text with the real behavior, reproduction steps, expected result, and version from the app's About menu or od --version.

What happened?

When referencing project files from the chat composer with @, entries whose names start with . never appear as suggestions — not one specific folder, but every dot-prefixed file and directory. Common ecosystem examples such as .github/, .vscode/, .storybook/, .husky/, or a plain .notes.md file are all invisible. Typing @.github produces zero suggestions even though the directory exists in the project. The same filter also excludes dot-prefixed entries from project-wide file search, so such content is unreachable from both the mention picker and search.

Steps to reproduce

1. Create a project (or import a folder) that contains a directory or file whose name starts with ., e.g. .github/ or .vscode/settings.json.
2. Open the project and focus the chat composer.
3. Type @ followed by the exact name, e.g. @.github.
4. Observe that no suggestion appears. A non-dot-prefixed name of the same shape does appear.

Expected behavior

Dot-prefixed user-content files and directories should be mentionable and searchable. Hiding system/generated directories (.git, daemon scratch dirs) from the UI is understandable, but the current implementation is a blanket startsWith('.') filter rather than an explicit ignore list, so it also hides legitimate user content that follows common dot-directory conventions.

Open Design version

0.16.1

Platform

Windows

Logs (optional)

Screenshots (optional)

No response

Additional context

No response

[open-design-bot]

🎉 ✨ Welcome to Open Design, @pollylol!

✨ 🔥 Lit the spark.

🌱 Your first contribution adds energy to the project. Thanks for showing up and helping Open Design grow.

💛 Thanks for helping Open Design grow. Keep building in the open. 🚀

🔗 Share on X (English) · 分享到 X（中文）

[lefarcen]

Hi @pollylol — thanks for the clear repro, especially the @.github example.

This looks confirmed from the current project-file path: both the file listing and folder listing helpers in apps/daemon/src/projects.ts skip any entry whose basename starts with ., and project search reuses that same file list. So the behavior isn't limited to one folder — it's a blanket hidden-file filter, which matches what you're seeing in both mention autocomplete and project-wide search.

We already have a narrower ignore-list for genuinely internal/generated dirs such as .git and .od, so the fix here should be to swap the broad dot-prefix exclusion for that more explicit policy. I've tagged this as help wanted because it's a reasonable community fix, but I left off good first issue since it touches shared project-file plumbing rather than just one isolated UI component.

[lefarcen]

If anyone in the community wants to pick this up, comment /claim and we’ll mark it as yours.

[mturac]

/claim

[lefarcen]

Thanks for picking this up, @mturac — appreciate it.

Roughly how long do you think it’ll take: a few hours, 1–3 days, around a week, or longer?

[lefarcen]

Update: @mturac opened #6214 for this.

That PR narrows the current blanket dot-prefix filter in apps/daemon/src/projects.ts so managed projects can list user-owned entries like .github/, .storybook/, or .notes.md, while still keeping internal/generated directories hidden and leaving imported-folder hidden-path behavior unchanged.

We’ll keep this issue open until the fix lands.

[lefarcen]

Hey @mturac, PR #6214 has been quiet for about a day and the current blocker is still the archive-export mismatch from @nettee's review. Anything you want another look at, or are you mid-iteration?