Pull Request

Thanks for helping improve Open WebUI. Please make sure the linked Issue or Discussion explains the user-facing problem, the expected outcome, and any relevant examples or constraints.

Code contributions are not the default path. Open a code pull request only when a maintainer asks for one, or for narrow i18n/localization updates. For real, reproducible bugs, start with a well-described Issue. For feature requests, UI/UX changes, behavior changes, architecture changes, suspected fixes, or unconfirmed approaches, start with an active Discussion.

If you have implementation notes, include them as reference in the Issue or Discussion. A local diff, patch, or branch can be useful context, but it does not mean a pull request is expected or will be reviewed.

Unsolicited PRs may be closed without review, especially when they introduce product, architecture, compatibility, dependency, or maintenance decisions that have not been discussed.

Checklist

• This PR targets the dev branch.
• This PR links to a confirmed Issue or active Discussion: Closes #29022.
• A maintainer explicitly asked me to open this PR, or this PR only updates i18n/localization.
• The change is one logical unit with no unrelated commits.
• I matched nearby code patterns and avoided unnecessary new settings, abstractions, or dependencies.
• I manually tested the changed workflow and any nearby behavior that could be affected.
• I updated relevant docs, including the Open WebUI Docs Repository, if needed.
• I added screenshots for UI changes, and a recording when motion or interaction matters.
• I reviewed any AI-generated code before submitting it.
• The PR title uses one of the prefixes listed below.

Title Prefix

Use one of the following prefixes:

• BREAKING CHANGE: Changes affecting backward compatibility
• build: Build system or dependency changes
• ci: CI/CD workflow changes
• chore: Refactoring, cleanup, or non-functional changes
• docs: Documentation additions or updates
• feat: New features or enhancements
• fix: Bug fixes or corrections
• i18n: Internationalization or localization changes
• perf: Performance improvements
• refactor: Code restructuring

Summary

Closes #29022.

Folder routes now reload the selected folder when the dynamic folderId route parameter changes. This keeps selectedFolder aligned with the current /folders/:folderId URL, including when navigating through nested folders or after moving a folder in or out of a parent folder.

The backend already applies folder project settings, including data.system_prompt, when the completion request contains the correct folder_id. Keeping the route store in sync prevents new chats opened from a nested folder from using stale folder context.

Testing

• npx prettier --check 'src/routes/(app)/folders/[folderId]/+page.svelte'
• npx eslint 'src/routes/(app)/folders/[folderId]/+page.svelte'
• git diff --check
• npx svelte-check --tsconfig ./tsconfig.json 2>&1 | Select-String -Pattern 'src\\routes\\\(app\)\\folders\\\[folderId\]\\\+page\.svelte' -Context 0,5

The filtered svelte-check command reported no diagnostics for the changed file. A full npm run check still reports existing repository-wide diagnostics unrelated to this change.

Changelog Entry

Added

Changed

Fixed

• Refreshed the selected folder when navigating between /folders/:folderId routes so nested folder chats use the current folder context.

Removed

Security

Breaking Changes

Additional Context

This change is intentionally scoped to the folder route state sync. It does not change backend folder permissions or folder project setting application.

Contributor License Agreement

• By submitting this pull request, I confirm that I have read and fully agree to the Contributor License Agreement (CLA), and I am providing my contributions under its terms.