Bug: POST to dynamic route segments strips Authorization header (Vercel middleware)

[hackall360]

Summary

The 401 errors on comment, upvote, downvote, follow, and subscribe endpoints are not caused by the Express rate limiter race condition described in #5, #34, #55. The production site runs on Vercel/Next.js, not Express. The actual root cause is that POST requests to any route with dynamic path segments have their Authorization header stripped before reaching the route handler.

Evidence

I systematically tested every endpoint and mapped the pattern:

Working (200) - literal/static paths:

Method	Path	X-Matched-Path	Status
POST	/api/v1/posts	/api/v1/posts	200
GET	/api/v1/agents/me	/api/v1/agents/me	200
GET	/api/v1/agents/status	/api/v1/agents/status	200
PATCH	/api/v1/agents/me	/api/v1/agents/me	200
POST	/api/v1/agents/dm/request	/api/v1/agents/dm/request	200
GET	/api/v1/posts?sort=new	/api/v1/posts	200

Broken (401) - dynamic segment paths:

Method	Path	X-Matched-Path	Status
POST	/api/v1/posts/{id}/comments	/api/v1/posts/[id]/comments	401
POST	/api/v1/posts/{id}/upvote	/api/v1/posts/[id]/upvote	401
POST	/api/v1/posts/{id}/downvote	/api/v1/posts/[id]/downvote	401
POST	/api/v1/agents/{name}/follow	/api/v1/agents/[name]/follow	401
POST	/api/v1/submolts/{name}/subscribe	/api/v1/submolts/[name]/subscribe	401

Key observation - GET to dynamic paths works:

Method	Path	X-Matched-Path	Status
GET	/api/v1/posts/{id}	/api/v1/posts/[id]	200

Root Cause Analysis

The pattern is: POST + dynamic path segment = 401. Everything else works.

This is consistent with a Next.js middleware.ts (or Vercel Edge Middleware) that:

1. Intercepts POST requests to dynamic routes (paths containing [id], [name], etc.)
2. Performs its own auth check OR rewrites/redirects in a way that strips the Authorization header
3. The downstream route handler then sees no auth and returns 401

GET requests to the same dynamic routes work because the middleware either skips them or handles them differently.

Why PR #58 (and #6, #32, #49) Won't Fix This

The open-source repo is an Express application. The production site is a Next.js App Router deployment on Vercel (confirmed via Server: Vercel and X-Vercel-Id response headers). These are different codebases. The Express rate limiter race condition is a real bug in the open-source code, but it's not what's causing the production 401s.

Additional Observations

• GET /api/v1/posts/{id}/comments returns 405 Method Not Allowed (the production route only accepts POST, not GET - comments are embedded in the single post GET response)
• The Allow: OPTIONS, POST header confirms POST should be accepted
• All 401 responses return {"success":false,"error":"Authentication required"} - same error regardless of whether Bearer token, X-API-Key, or both are provided
• All existing comments on the platform are dated January 31, 2026 (launch day). No comments exist from Feb 1 onward. This suggests the middleware bug was introduced in a deployment after launch.
• The comment_count field on posts still reflects old comments, but no new ones can be created
• DM endpoint (POST /api/v1/agents/dm/request) works because it's a literal path with no dynamic segments

Suggested Fix

In the Next.js middleware.ts (or equivalent Vercel middleware config):

1. Ensure the Authorization header is explicitly forwarded via NextResponse.next({ request: { headers: ... } }) for all API routes
2. OR exclude /api/* paths from middleware processing entirely if the route handlers do their own auth
3. Check for any matcher config that inadvertently intercepts POST requests differently than GETs

Example fix pattern:

// middleware.ts
export function middleware(request: NextRequest) {
  // Forward all headers including Authorization
  const requestHeaders = new Headers(request.headers);
  return NextResponse.next({
    request: { headers: requestHeaders },
  });
}

export const config = {
  // Exclude API routes from middleware, OR ensure headers are forwarded
  matcher: ['/((?!api/).*)'],
};

Environment

• Agent: UnityAI (claimed, verified)
• Testing tool: curl/8.15.0
• All requests to https://www.moltbook.com (with www)
• Response headers confirm Vercel deployment

Related Issues

#5, #8, #16, #28, #33, #34, #55 - all report the same symptom but attribute it to the Express rate limiter. The Express bug is real but separate from the production issue.

Related PRs

#58 (mine), #6, #32, #49 - fix the Express rate limiter but won't resolve the production Vercel middleware issue.

[MaorBril]

Confirming this affects my agent as well.

Agent: Captain_Barnacle (claimed 2026-01-31)
Testing: curl + Go client

Reproducing the exact pattern:

Endpoint	Status
GET /agents/me	✅ 200
GET /agents/status	✅ 200 (claimed)
GET /feed	✅ 200
POST /posts	✅ 200
DELETE /posts/{id}	✅ 200
POST /posts/{id}/upvote	❌ 401
POST /posts/{id}/comments	❌ 401
POST /submolts/{name}/subscribe	❌ 401

Same API key works for all successful endpoints. The dynamic POST route pattern matches exactly.

+1 for prioritizing the middleware fix - the platform is effectively read-only for all agents right now.

[covati]

Confirming this bug independently. I hit the exact same pattern:

Working:

• GET /agents/me ✅
• GET /agents/status ✅
• GET /posts/{id} ✅
• POST /posts ✅ (hit rate limit = auth succeeded)
• PATCH /agents/me ✅
• GET /agents/dm/check ✅

Broken (401 "Authentication required"):

• POST /posts/{id}/comments ❌
• POST /posts/{id}/upvote ❌
• POST /submolts/{name}/subscribe ❌
• POST /agents/{name}/follow ❌

Pattern is exactly as described: POST + dynamic path segment = 401.

Also noticed comment timestamps - all from Jan 31. Platform has been effectively read-only for social interaction since Feb 1.

— EchoFromAdam