feat(daemon): add link code folder support for agent context

[encyc]

Summary

Enables the "Link code folder" import menu item so users can link local code directories to a project. The AI agent then reads the linked source code via --add-dir when generating designs, giving it full context of the user's codebase.

• Daemon: New POST /api/dialog/open-folder endpoint opens a native OS folder picker (osascript on macOS, zenity on Linux, PowerShell on Windows). Linked directories are validated (absolute path, exists on disk, is a directory, not a sensitive system path), stored in metadata.linkedDirs on the project record, and appended to extraAllowedDirs in startChatRun so the agent receives them via --add-dir.
• Web: The "Link code folder" import item is now clickable. After the user picks a folder, it appears as a removable chip below the chat input. Chips show the folder basename, display the full path on hover, and can be removed with an X button.
• Contracts: linkedDirs?: string[] added to ProjectMetadata.
• i18n: Strings added for all 16 locales with native translations.
• Tests: 8 unit tests for validateLinkedDirs covering valid paths, relative paths, non-existent dirs, files, duplicates, and normalization.

No new dependencies. No database migration (uses the freeform metadata_json column). No changes to agent adapter code — the existing extraAllowedDirs → --add-dir pipeline is reused.

Test plan

• pnpm --filter @open-design/daemon test — 436 tests pass (including 8 new)
• pnpm --filter @open-design/web typecheck — clean
• Manual: open project chat → click Import → Link code folder → native picker appears
• Manual: select a directory → chip appears below input → send message → agent reads linked files
• Manual: click X on chip → directory unlinked → PATCH confirmed in network tab
• Manual: verify on macOS, Linux, Windows that native folder dialog opens
• Verify no regression on other import menu items (all still disabled as before)

[lefarcen]

Hi @encyc! 🎉

Thanks for the contribution — this is a well-scoped feature with solid testing and i18n coverage.
I will run a deep review and get back to you within 24h.

Thanks for making open-design better!
— open-design team

[mrcfps]

@encyc thanks for the well-scoped feature work here. I found one build-blocking issue in the new daemon source that needs a small typing fix before this can merge.

_{Generated by Looper 0.5.4 · runner=reviewer · agent=opencode}

[encyc]

Add import -> Link code folder

Test feature

[chatgpt-codex-connector]

💡 Codex Review

Here are some automated review suggestions for this pull request.

Reviewed commit: 79442739ce

ℹ️ About Codex in GitHub

Your team has set up Codex to review pull requests in this repo. Reviews are triggered when you

• Open a pull request for review
• Mark a draft as ready
• Comment "@codex review".

If Codex has suggestions, it will comment; otherwise it will react with 👍.

Codex can also answer questions or update the PR. Try commenting "@codex address that feedback".

[mrcfps]

@encyc thanks for tightening up the link-folder flow and addressing the earlier feedback. One TypeScript build blocker still remains in the new daemon helper, so I’m requesting one more small change before merge. 🙂

_{Generated by Looper 0.5.4 · runner=reviewer · agent=opencode}

[lefarcen]

Thanks @encyc for addressing the typing issue! The JSDoc annotations should satisfy TypeScript strict mode.

Code review (Lens A):

• ✅ Security: Solid validation — absolute path enforcement, blocked system directories, existence + isDirectory checks, and deduplication. No path traversal risk.
• ✅ Tests: 8 unit tests cover the critical edge cases (relative paths, non-existent, files vs dirs, duplicates, normalization).
• ✅ Error handling: The validation returns structured errors with clear messages.
• ✅ Architecture: Clean separation (validateLinkedDirs helper → server.ts PATCH endpoint → web UI chips). Reuses existing extraAllowedDirs pipeline.

Minor observation (non-blocking): linked-dirs.ts line 18 checks !path.isAbsolute(d) then line 20 does path.resolve(d), which always produces an absolute path. The isAbsolute check before resolve is technically redundant (resolve already handles relative inputs), but keeping it makes the error message clearer for users who pass relative paths, so it's fine as-is.

Overall this is production-ready. The typing fix addresses mrcfps's blocking feedback. No security or correctness issues found.

Looks good to me; deferring final approval to a maintainer.

[lefarcen]

Perfect! The TypeScript annotations are now inline as requested.

Current head ():

• ✅ Explicit TS parameter type: dirs: unknown
• ✅ Explicit TS return type: { dirs: string[]; error?: undefined } | { error: string; dirs?: undefined }
• ✅ Validated array typed: const validated: string[] = []

This resolves mrcfps's blocking feedback. The daemon package will now type-check correctly with strict mode enabled. All prior review points (security validation, test coverage, architecture) remain solid.

Looks good to me; deferring final approval to a maintainer.

[lefarcen]

Perfect! The TypeScript annotations are now inline as requested.

Current head (cead90b):

• ✅ Explicit TS parameter type: dirs: unknown
• ✅ Explicit TS return type: { dirs: string[]; error?: undefined } | { error: string; dirs?: undefined }
• ✅ Validated array typed: const validated: string[] = []

This resolves mrcfps's blocking feedback. The daemon package will now type-check correctly with strict mode enabled. All prior review points (security validation, test coverage, architecture) remain solid.

Looks good to me; deferring final approval to a maintainer.

[mrcfps]

@encyc thanks for the quick follow-up on the earlier typing and UI-state feedback. I found two linked-folder validation gaps that can still widen agent filesystem access beyond the intended policy, so I’m requesting changes before merge. 🙂

_{Generated by Looper 0.5.4 · runner=reviewer · agent=opencode}

[lefarcen]

mrcfps's latest review (14:59) found two filesystem security gaps that I missed earlier — both are P1. The inline comments on linked-dirs.ts and server.ts point to the exact validation bypasses. These need to be fixed before merge.

Sorry for the earlier "production-ready" assessment — I should have caught the root/symlink bypass and the project-creation validation gap.

[lefarcen]

Both P1 security fixes look correct on c68c125:

Path validation bypass (mrcfps comment 3182461516):
✅ Now uses fs.realpathSync.native() to canonicalize paths and follow symlinks
✅ Rejects filesystem roots (/, C:\)
✅ isBlocked() now checks both descendants AND ancestors (line 28: p.startsWith(realPath + path.sep))
✅ BLOCKED_CANONICAL pre-canonicalizes blocked paths to handle macOS /etc → /private/etc
✅ Tests cover: root rejection, symlink-to-blocked-dir, symlink resolution

Project creation bypass (mrcfps comment 3182461522):
✅ Project creation validates linkedDirs (server.ts:822-832), drops invalid entries
✅ startChatRun re-validates before use (server.ts:2502-2505), defensive double-check
✅ Invalid paths never reach extraAllowedDirs

Waiting for mrcfps to re-review the current head.

[mrcfps]

Approved.

[mrcfps]

Hi @encyc! Thanks for the work here — looks like CI is currently failing on Validate workspace. Could you take a look when you get a chance? 🙏

[encyc]

Hi @encyc! Thanks for the work here — looks like CI is currently failing on Validate workspace. Could you take a look when you get a chance? 🙏

fix in latest commit d99282a, please try again, thanks ^ ^.

[lefarcen]

Hi @encyc — I verified the latest push (d99282a) and it still has unguarded result.error accesses in the test file:

• Line 26: result.error.includes('does not exist')
• Line 35: result.error.includes('not a directory')

These need result.error! or an explicit guard before calling .includes(...) to pass CI's strict TypeScript check. The return type is { dirs, error?: undefined } | { error, dirs?: undefined }, so TS treats error as possibly undefined unless narrowed.

Quick fix: change those lines to result.error!.includes(...) (or wrap in if (result.error) { assert.ok(result.error.includes(...)); } if you prefer the guard style).

[mrcfps]

Thanks again @encyc for the thoughtful work and the quick follow-ups here. I really appreciate how promptly you addressed the CI/typecheck issue and tightened the validation details along the way. CI is green now, and this looks good to me — nice work pushing this feature through! 🙌

[lefarcen]

Thanks again @encyc for the thoughtful iteration on this feature and the quick security/typing fixes throughout the review! 🎉 The link-folder validation is now solid, and the pipeline gives users full codebase context. Really appreciate the careful follow-through here.

— open-design team