Repository navigation
Cannot use icon.tsx within catch-all segment route #77061
Description
Link to the code that reproduces this issue
https://github.com/damnsamn/create-next-app/tree/issue/icon-catch-all
To Reproduce
- Run
npm run dev- you will receive the following error in the terminal:
FATAL: An unexpected Turbopack error occurred. Please report the content of /var/folders/s1/9zgpmd351296lr0g8zwkw0xh0000gn/T/next-panic-8fa406967be804ab5ebe277752e3ffb0.log, along with a description of what you were doing when the error occurred, to https://github.com/vercel/next.js/issues/new?template=1.bug_report.yml
[Error [TurbopackInternalError]: Invalid segment Static("icon"), catch all segment must be the last segment modifying the path (segments: [CatchAll("slug")])
Debug info:
- Execution of get_entrypoints_with_issues_operation failed
- Execution of EntrypointsOperation::new failed
- Execution of Project::entrypoints failed
- Execution of AppProject::routes failed
- Execution of directory_tree_to_entrypoints_internal failed
- Execution of directory_tree_to_entrypoints_internal failed
- Invalid segment Static("icon"), catch all segment must be the last segment modifying the path (segments: [CatchAll("slug")])]- Delete or rename
[...slug]/icon.tsxto disable it. - run
npm run devand see that we can get running just fine.
This also occurs for optional catch-alls
Current vs. Expected behavior
We're trying to implement a pattern where the favicon returned for a given route is themed based on the page's own theme - which we need to access the route params to be able to determine. We are fulfilling the same use case on https://www.humaan.com/expertise/headless for example - but that project is using static/dynamic routes without any catch-alls.
I would expect that we can tack icon.tsx anywhere in the app router structure and it would be handled correctly at that level. Being a static nested route though, this is causing issues.
Provide environment information
Operating System:
Platform: darwin
Arch: arm64
Version: Darwin Kernel Version 24.0.0: Mon Aug 12 20:52:31 PDT 2024; root:xnu-11215.1.10~2/RELEASE_ARM64_T6030
Available memory (MB): 18432
Available CPU cores: 12
Binaries:
Node: 22.12.0
npm: 10.9.0
Yarn: N/A
pnpm: 9.15.6
Relevant Packages:
next: 15.2.2 // Latest available version is detected (15.2.2).
eslint-config-next: 15.2.2
react: 19.0.0
react-dom: 19.0.0
typescript: 5.8.2
Next.js Config:
output: N/AWhich area(s) are affected? (Select all that apply)
Dynamic Routes
Which stage(s) are affected? (Select all that apply)
next dev (local), next build (local), next start (local), Vercel (Deployed), Other (Deployed)
Additional context
No response
Activity
good-jinu commentedon Apr 5, 2025
The way icons are generated is based on the route structure. For example, if the route is at the root level, the icon is generated at
/icon. If it's inside a[slug]folder, the icon is created at/[slug]/icon. However, with catch-all segments, it's unclear where the icon should be placed, which leads to ambiguity and potential issues.Currently, the documentation (Generate icons using code) only provides examples for static and dynamic routes, without covering catch-all segments. Since metadata like icons are treated as static assets, it would be helpful to include a warning or guidance in the error message that explains why catch-all segments aren't supported for this use case. It could also suggest using dynamic routing as a more appropriate alternative.
marcoshernanz commentedon Aug 24, 2026
Thanks for the report. This is the same unsupported route shape tracked in #49630. A generated
icon.tsxis registered as a nested metadata route such as/[...slug]/icon, but a catch-all must be the final URL segment, so the route cannot be matched. We removed the catch-all icon example from the docs in #66355 for this reason. Please use a separate Route Handler for the image and reference it fromgenerateMetadata. Closing as a duplicate.opengraph-imagecan't be used to accept params in catch-all routes (Error: Catch-all must be the last part of the URL.) #49630github-actions commentedon Aug 24, 2026
This issue was closed by a maintainer. If you think it was closed by mistake, you can request that it be reopened within the next 14 days.
Reply with
Reopen: <reason>and explain why the issue is still relevant. If you opened this issue or commented before it was closed, the issue will be reopened automatically.After 14 days, please open a new issue with up-to-date details and a reproduction, when applicable.
github-actions commentedon Sep 7, 2026
This closed issue has been automatically locked because it had no new activity for 2 weeks. If you are running into a similar issue, please create a new issue with the steps to reproduce. Thank you.