Severity
Reports at this severity, newest stored first.
The @next/codemod agents-md command computes the docs root path relative to the current working directory rather than the directory of the `--output` AGENTS.md file. In monorepos where the output file is at a different location (e.g. repo root) and Next.js is installed only in a workspace package, the generated root path is broken, causing agent tools to read nonexistent documentation paths.
When using ChatOllama with tool calling, ToolMessages are sent without the required tool_name field, so Ollama renders them as coming from an unknown tool. This breaks tool result matching for models that rely on the name, like Gemma 4.
ShellToolMiddleware currently defaults to HostExecutionPolicy, allowing arbitrary shell commands with only LLM guardrails. This feature request proposes an allow_list parameter to restrict executable commands, mitigating the risk of dangerous operations.
Project zvusdpixljxkxlxrrauj (Pro) experiences 5xx/504 errors on /auth/v1/* during weekday business hours, primarily affecting token refresh and user lookup endpoints. The issue is likely caused by database connection pool exhaustion in the GoTrue auth service under concurrent load, leading to requests exceeding the 60-second timeout.
When a native form POST (no JavaScript) targets a partially prerendered page, the Server Action executes but the response is only inlined Flight data with no HTML shell, leaving a blank page.
The LinkedIn OIDC provider builds its OAuth authorization and token URLs against api.linkedin.com instead of LinkedIn's documented www.linkedin.com endpoint, causing users with an active linkedin.com session to be forced to log in again on every sign-in attempt.
When Next.js is invoked from a directory other than the project root, relative imports in next.config.ts are resolved against the current working directory instead of the configuration file's own directory, leading to module resolution failures or loading incorrect files.
When Next.js is invoked from a directory other than the project root (e.g., `node app/node_modules/next/dist/bin/next build app`), relative imports in `next.config.ts` are resolved against `process.cwd()` instead of the config file's directory. This causes builds to fail with `Cannot find module` or silently load a wrong file if a similarly named file exists in the cwd. The issue affects the default SWC transpilation path and has been present since Next.js 15.0.0.
When building a Next.js project with next.config.ts from a working directory different from the project root, relative imports inside next.config.ts are resolved relative to process.cwd() rather than the config file's location. This causes module-not-found errors or, worse, silently loads a file with the same relative path from the current working directory, potentially applying unintended configuration.
The Table Editor's updateTable function incorrectly compares primary key column names in display order against the primary_keys array (which is in key order). This false mismatch causes the primary key constraint to be dropped and re-added, leading to save failures when foreign keys reference the primary key, or silent reordering of composite primary keys.
updateTable compares PK column names in display order with primary_keys from the database (key order), causing a name change or an out-of-order composite PK to be treated as a PK change. Studio then drops and re-adds the PK in separate transactions, which fails when foreign keys reference it or silently reorders the PK.
Feature request to add SiaMeshTool that scrapes web content via a third-party endpoint using x402 Solana USDC micro-payments. The endpoint is not officially vetted and could expose users to prompt injection, SSRF, or financial loss if compromised.
updateTable compares primary key column names in display order with the backend's primary_keys array (which comes back in key order). A rename or an out-of-order composite primary key like (b, a) is falsely detected as a PK change, causing Studio to drop and re-add the constraint in separate transactions. This fails when a foreign key references the primary key, blocking unrelated edits, or silently rebuilds the constraint and reorders columns when no FK exists.
The feature request proposes adding a SiaMeshTool that uses x402 micropayments and sanitized scraping. Without proper validation, error handling, and security review, this could expose agents to malicious endpoints, prompt injection, and payment interception.
The feature request proposes adding a SiaMeshTool that scrapes URLs via a hardcoded third-party endpoint with x402 micro-payments. If implemented naively, it exposes LangChain agents to SSRF attacks aimed at internal services and allows unauthorized micro-payments.
After upgrading to Next.js 16.3.8, deployments that patch the existing .next directory in place (rather than recreating it) leave stale route-cache entries, causing 404s for CSS/JS assets. The root cause is that the route-cache key no longer includes a build identifier, so cached entries from the previous build remain valid after a new deploy.
Next.js 16.3.8 introduced a regression where the route-cache key no longer depends on the build ID. In non-atomic in-place deployments that patch the .next directory without clearing .next/server/route-cache, stale cache entries reference old hashed assets, causing 404s for CSS and JS files after deployment.
After an in-place deployment that patches the .next directory without clearing runtime caches, Next.js 16.3.8 and 16.4.0-canary.60 reuse stale route-cache entries, causing 404s for CSS and JS assets. The regression is linked to PR #99482, which changed the route cache key to no longer depend on the build output.
User reports project gcizehgpcztmqtqhveng is healthy in dashboard but its default supabase.co hostname resolves to NXDOMAIN; DNS record missing or not propagated.
When using next/font/google with adjustFontFallback: false, the generated CSS still includes the automatic fallback font family, causing the fallback to always be applied. This is a regression from Next.js 14.
Google Fonts occasionally returns extensionless URLs with a format('woff2') hint. Next.js font loaders assume a file extension in the URL, causing webpack to crash with a null regex match and Turbopack to split the URL query on '&', resulting in intermittent build failures.
The grep_search method in FilesystemFileSearchMiddleware fails to fall back to the Python search when ripgrep exits with an error (return code 2), because _ripgrep_search returns an empty dict instead of None when ripgrep rejects the regex pattern. This leads to a false 'No matches found' response for valid Python regexes like look-ahead/look-behind. Additionally, the max_file_size_mb parameter is not applied to the ripgrep command, causing inconsistent results between ripgrep and Python fallback paths.
When a client that has loaded a page from Next.js 16.1 performs a soft navigation (Link click) after the server is upgraded to 16.2, the old-format router state header sent by the client cannot be parsed by the new server, causing a 500 error. The issue only occurs when dynamic rendering is involved (e.g., using cookies()) because such requests always hit the server for RSC payload validation.
In Next.js 16.3.6 and 16.3.8, a render error during an in-flight server action causes the shell to suspend repeatedly, eventually throwing minified React error #482 and replacing the page with 'This page couldn't load' instead of rendering error.js.
The default `text_format='string'` path in `convert_to_openai_messages` directly accesses `block["type"]` while collapsing content blocks, causing a `KeyError` for legitimate Bedrock Converse content blocks that lack a `type` key. The same blocks pass through correctly when `text_format='block'` is used, violating the promise of `pass_through_unknown_blocks=True`.
Soft navigation breaks with a 500 error when a client that loaded a 16.1 app navigates after a server upgrade to 16.2, because the router state header format/encoding changed and the new server parser throws instead of falling back to a full navigation. The issue only occurs when at least one layout or page is dynamically rendered (e.g., uses cookies()).
After upgrading from Next.js 16.1 to 16.2, clients holding stale router state from the previous deployment send a header that the newer server cannot parse, causing a 500 error and failed soft navigation on dynamic routes/pages.