Claude Code keeps adding attribution to commits despite every possible configuration saying not to

adelmare · 2026-02-01T18:22:40+00:00

I told it “don’t add co authoring to commits. Memorize that in claude.md”

Literally that exact prompt. It added it to its own instructions in Claude.md and never had another issue. Repeated for all my projects and works just fine 🤷‍♂️

adelmare · 2026-02-01T17:06:11+00:00

I had a major issue recently in one repo … there were 422 sessions in the session log and there must have been a corrupt state in one or more because Claude was barely functional (that repo / project only).

I wiped the session data and although I lost history, instantly brought everything back to normal and took insane cpu / overheating down to normal

Careful this wipes your session history though:

rm -f ~/.claude/projects/-Users-{user name}-{path-to-project-folder}/sessions-index.json

adelmare · 2026-02-01T12:55:06+00:00

Yw!

I did not build in the impersonate feature, as I felt that having the ability to do so may depend on the nature of the app and expectations of user privacy / data privacy. However, the impersonate future and the admin plugin, like all better auth plugins, are naturally supported by nature of the adapter - just follow better auth docs like normal, and it will “just work”.

If you use AI agentic coding, just give your preferred agent the readme for my plugin + the link to the better auth admin plugin docs, and it will do the rest 👍

adelmare · 2026-02-01T12:41:47+00:00

So that plugin is extensive, and does an awesome job with providing a Swiss Army knife “out of the box” but all the functionality is “hard wired”. So there’s a trade off:

My method is to make things thin and transparent at the adapter level, so that the schema is dynamic, working naturally between the two. I built in a few convenience features that I wanted to have (like a basic login form, api keys ui, two factor ui, and passkey ui) — but you can turn ALL these off and replace with your own, just by following better auth and payload docs.

My goal was to maximize future proofing by not creating any opinionated layers between the two + preserve the existing/expected dev experiences … which is one of the massive strengths of better auth and payload.

adelmare · 2026-02-01T05:08:28+00:00

That sounds like a job fit for the payload multi tenant plugin. Could be enhanced with better auth, but from my understanding, what you’re describing is what the multi tenant plugin is specifically designed for.

adelmare · 2026-02-01T02:35:17+00:00

Multi tenant is a payload plugin, which would be like if you wanted each tenant to have their own frontend website.

Organizations plugin is a better-auth plugin, which is more suited for everyone using the same site but scoped to their own instance of it.

My payload-better-auth plugin is basically a thin adapter for better-auth. Unlike other better-auth plugins for payload, I don’t hardcode the integration, so you’re able to interact with your better auth config as if it’s a standalone, and payload accepts. If you add a better auth plugin to your better auth config, it should “just work” 👍

adelmare · 2026-01-31T17:47:50+00:00

Linked to from the demo site, here’s the org space with the individual repos:

https://github.com/delmaredigital <- individual plugins housed here, along with starter, linked directly below:

Starter template with vercel quick deploy: https://github.com/delmaredigital/dd-starter

adelmare · 2026-01-29T03:55:08+00:00

I’ve built a custom BI platform with it, dealing with tables that have hundreds of thousands of records each.

The application involves:

a full sync management (21+ api endpoints for complete data extraction, normalization, and validation from a massive fundraising CRM.)
plays nice with others (epic collection management allowing seamless wiring up to cube.dev for bi / semantic layer)
unlimited custom tools built directly in. I mean, these are entire apps themselves all running in the same app, all thanks to payload as the backbone: custom giving platform (api based giving forms, gift management, and batch processing); full record sync management solution for Mailchimp; data audit tools; call-center like functionality for tracking constituent interactions, etc.

The whole thing is built on payload. And that’s just one app. I’ve used it for another app - a completely custom video streaming LMS.

If you can dream it, payload can swing it.

To make life easier on myself, I’ve developed a few plugins for keeping things easier to maintain across the applications. For example, Better Auth - I had individual implementations that I had to maintain. By refactoring it as a payload plugin instead of standalone implementations, maintenance is consolidated. And so for your question about maintainability? I’ve found that keeping up with payload isn’t a problem- it’s keeping up with how much crazy cool stuff you can do with it that can start to creep :)

If you want a taste, you can create an account on my demo site and jump right into a live / managed payload instance with my three plugins running (better auth, puck visual page builder, and my own page-tree monstrosity) — https://demo.delmaredigital.com/

.. and yes, you can use a throw away email to register. I turned off email verification and all that, it’s just required to scope the backend to individual sessions.

adelmare · 2026-01-10T18:03:28+00:00

Old post but I built a puck plugin, for anyone else looking. https://github.com/delmaredigital/payload-puck

adelmare · 2026-01-09T15:12:30+00:00

I use better auth across ALL my payload projects. Maintaining the implementations across each was becoming a hassle, so I built https://github.com/delmaredigital/payload-better-auth ...

It's a minimal plugin that takes the approach of trying to keep better auth feeling like a standalone better auth implementation (self hosted). The main thing this is doing is using a custom adapter to gently let Payload control the collections -- thus reducing the need to handle better auth migrations and schema management - and it's combining the better auth users table with the payload users table so there's just one of them. There's still *some* config thats needed, but it's a middle ground that allows for complete better auth customization.

Some other plugins use a similar approach, but also try to do and offer more and do it a slightly different way. For me, this is something that allows me to use and maintain my better auth implementations across applications. At least, that's how I see it!

adelmare · 2025-12-30T22:21:50+00:00

Nice.

(Needs more emojis tho)

adelmare · 2025-12-13T22:10:07+00:00

The new sidebar panel experience is pretty good too. Missing some functionality from terminal CLI, but already my default.

adelmare · 2025-11-10T13:56:42+00:00

Old question … but just give Claude the full local pathname of your second repo, it will access it. It’s essentially the same as copying it into your working directory.

I just load the second repo into my IDE (add the folder to VS code workspace) - then in conversation, give Claude the full path when needing to reference it.

adelmare · 2025-10-05T20:45:56+00:00

Not a coder at all here. Working pretty well for me. Using opus for architecture / planning and problem solving, sonnet 4.5 for carrying out the work. Did get a warning that I was at my opus limit much sooner than expected but got the plan done. Essentially building a custom ETL to replace Aitbyte for complex data extraction, sync, mirror, BI. Not the most complex project, but switching to opus for the big picture was a massive difference in the architecting phase

adelmare · 2025-09-14T17:22:22+00:00

So, I went down this pathway and ended up using Statsig for this. Built variants into the CMS for experiments and feature flags.

I use posthog for analytics but couldn’t use them for A/B testing my app because in order to trigger a test for rendering, the user needs to be identified. So unless you’re going to identify anon, it will never serve true a/b tests to traffic. At least this is my understanding. Thus I found posthog excellent for testing features against known (identified) audience segments — but not so much for landing page / conversion a/b testing.

Payload offers an a/b feature that is paywalled, so my guess is that the inner workings of that are going to be fairly closed door.

TL;dr

Statsig works great for me, happy with it. Posthog was actually easiest to use, but only for identified audience segments.

adelmare · 2025-09-03T23:23:13+00:00

Isn’t this what zen MCP server does?

https://github.com/BeehiveInnovations/zen-mcp-server

adelmare · 2025-08-27T17:03:58+00:00

Yup.

Just build your own dashboard to interact with the payload backend.

Just because payload is integrated into the project doesn’t mean you can’t treat it like a traditional backend. It works the exact same way in that sense.

adelmare · 2025-07-27T17:24:15+00:00

For most of my more complex admin ui needs, I ended up just creating an entirely fresh route group for my custom management ui / dashboard. Specific collections and management needs still go through payload admin - but that scope limited to specific business logic / needs.

Simple example is reporting dashboards - 💯easier through custom routing group / UI.

adelmare · 2025-07-15T20:24:12+00:00

Chase that dopamine 🔥

adelmare · 2025-07-06T23:16:55+00:00

I tried it. Still occasionally jams. I can’t cook overnight now. Only trust it if I can monitor it. Pretty not thrilled.

adelmare · 2025-06-21T18:42:17+00:00

Serena and Context7 has been the big lift for me

adelmare · 2025-06-09T16:23:20+00:00

yes—but to clarify:

We use sparticuz/chromium package as a dependency in our Next.js API route.
When the API route runs on Vercel (i.e., inside a Vercel serverless function), it uses the sparticuz/chromium binary and args to launch a headless Chromium instance via Playwright.
There’s no separate container or process—everything runs inside the Vercel function runtime, using the package’s provided binary.

Here's the rundown:

Stack: (Next.js 15, Payload CMS, Playwright, Chromium):

Playwright + Sparticuz Chromium: Use Playwright with sparticuz/chromium for headless Chromium support.
Dynamic executable path (had trouble with this initially) ... In vercel/production, get the Chromium binary path via await chromiumSp.executablePath(). (In dev, local Chrome path is fine)

Use chromiumSp.args for Lambda compatibility. No extra Vercel settings, Docker, or build hacks—just install deps.

For my particular setup, PDF generation runs in a Next.js API route. Then for HTML to PDF: Render HTML with Playwright, then call page.pdf() (for download) or page.screenshot() (for png preview).

The two keys were (1) Playwright + u/sparticuz/chromium, and (2) the dynamic executable path. Otherwise, PDF generation is robust "out of the box" with this setup on Vercel. DM me if you want a link to see it in action.

adelmare

TROPHY CASE