[▲ Vercel Community](/) · [Categories](/categories) · [Latest](/latest) · [Top](/top) · [Live](/live) [Help](/c/help/9) # Vercel build fails with "Unable to unpack repo: there was at least one filename that was too long" 20 views · 1 like · 6 posts ben (@benrucker) · 2026-04-06 ## Problem Suddenly, my builds are failing for my project. There are only four build log lines. There’s the build location, machine, repo + commit, and the error: > **Error: Unable to unpack repo: there was at least one filename that was too long** ## Context Unfortunately, this repo is not public, so I can’t directly link this exact repro. However, the longest filename in the repo from the repo root is 181 characters long. This figure did not change between the last working build and the first failing build. - **Framework:** `Next.js 16.1.1-canary.11` - **Environment:** Monorepo, "Include files outside the root directory in the Build Step" enabled. - **Build Machine:** `Standard`. A few days ago, I started getting `Unable to unpack repo: there was at least one filename that was too long` build failures on my project. No deployment since then has succeeded; all builds fail with this reason. The commit that first resulted in this failure did not add a file with a long name, making me wonder if this was a configuration/build env change. ## Questions There is no additional information beyond the four build log lines. So it would be nice if I could figure out the following: 1. Which file (or files) is over the limit? 2. What the limit is? 3. Whether the limit is relative to the repo root or the build machine’s root? In terms of my configuration on Vercel, it seems like the build is failing before my build command is executed, so that must not be the problem. I’m deploying an app that is a package in a monorepo. I do have "Include files outside the root directory in the Build Step" on because there is a file from another package I’m depending on. Ultimately, additional visibility into the error would be much appreciated! In lieu of that, I will have to start making guesses about what to change to get my builds to succeed again. Or, as Claude recommends, move to GitHub actions for deployment. Swarnava Sengupta (@swarnava) · 2026-04-06 · ♥ 1 Hi, do you have `git config --global core.longpaths true` configured locally? configuring git settings such as **core.longpaths** directly within the platform is not supported at the moment. Apologies for the inconvenience. I’ve shared the feedback with the concerned team. As a workaround, you might consider restructuring your repository to avoid long file paths or deeply nested directories, which could help mitigate the unpacking error. You can also try deploying the app using **Vercel CLI.** Can you please try the **vercel deploy** command and see if it works? Please refer to this guide for more details - [https://vercel.com/docs/cli/deploy](https://vercel.com/docs/cli/deploy) ben (@benrucker) · 2026-04-09 Thanks for the quick reply! I do not have `git config –global core.longpaths true` either in my or my team’s machines, nor in the repository’s git settings. We’re all on Windows, if that makes a difference here. I’ll read up on `vercel deploy` and try it out, thank you. Swarnava Sengupta (@swarnava) · 2026-04-09 Do you have a minimal repro that I can see to investigate? ben (@benrucker) · 2026-04-11 I took a second to initialize a new public repo that includes the longest file path from the private repo. However, I can’t get it to fail at the cloning step. `link removed` So, maybe it’s something in the real project’s git history that has the side effect of *creating* a file with a long name, like something in the `.git` folder itself during initial cloning. ben (@benrucker) · 2026-04-11 Root cause found. Claude Opus 4.6 debugged the real repo until it noticed a malformed symlink. As it turns out, this symlink was created and committed to git, then later on, I changed the contents of the file to be actual, unique contents instead of a symlink, but I failed to change the type of the file in git from symlink back to a normal file. So the “path” that the symlink pointed to was thousands of characters of markdown content, rather than a regular filepath. Fixing the type of the file in git from `120000` to `100644` fixed the issue and allows deployments to succeed. So, not a Vercel bug, just a super niche git edge case caused by my own error. Thanks for the responses! All good now.