NHCarrigan

Redesigning NHCarrigan

naomi@nhcarrigan.com (Naomi Carrigan) — Fri, 16 Oct 2026 21:36:04 GMT

On 14 October 2026 we released a redesign of nhcarrigan.com, our documentation, our forms and every site that uses our shared page script.

This is a redesign. It is not a rebrand. The name, the logo and the colour palette have not changed. What has changed is how the palette is applied.

This post explains what we were trying to achieve, how the new look works, how we checked that it stays readable, what went wrong along the way, and what it means for you. It is long on purpose. If you want the short version, start with the next section.

In short

The site now uses frosted glass surfaces, lit by a single rose light source.
Every NHCarrigan site now has the same header and the same footer.
Dark mode has been removed from all of our sites.
The homepage has been reworked to make it easier to start a conversation with us.
A new FAQ page answers 62 questions in one place.
Version 6 of our shared page script is a breaking change for developers. Migration notes are further down.

Before After

What we were trying to achieve

We had three goals.

One site, not several

Before this change, our homepage, our documentation, our forms and our small apps shared a colour palette and little else. Some pages had a header. Some did not. The footers differed. A visitor moving between them could reasonably wonder whether they were still on our site.

We wanted every page to look and behave like part of one product.

A clearer path for people deciding whether to work with us

NHCarrigan sells services. The homepage has to answer three questions quickly. What do you do? Can I trust you? How do I start?

Most of the changes to the homepage exist to answer those questions with less effort from the reader.

Nothing that costs readability

This was the rule that limited everything else. Any effect had to survive a contrast measurement. If an effect made text harder to read, the effect was removed or changed. We did not add decoration for its own sake.

How the look works

One light source

The palette has not changed. Witch Rose, Witch Plum, Witch Purple and Witch Black are the same colours as before. The difference is that they now behave as if a single lamp lit the page.

The lamp is in the upper right. Light arrives from that direction on every surface. The left side, where most text sits, stays in shadow. Shadows are plum and black. We use no second accent colour. The effect comes from light set against dark, and from keeping the direction the same everywhere.

On dark sections, the light appears as a glow. On light sections, light cannot glow in the same way, so it appears as colour bleeding in from the corner, a sheen along card edges, shadows tinted rose and plum, and a rose edge glow thrown towards the light.

Before After

Glass needs something behind it

Frosted glass only shows when there is colour behind it. A glass card on a plain background looks like a white box. For that reason the light sections carry soft rose and mauve washes, and the cards sit on top of them.

The header is dark glass at 72 per cent opacity with an 18 pixel blur, floating 12 pixels from the top of the window. Cards are white glass. On the shared pages, the background artwork is frosted over by the same rose and lavender wash, so the artwork shows softly through it.

Rules we set ourselves

Glow is never animated. There is one exception. On the company site, the dot beside our availability notice pulses slowly. It stops for readers who ask their device for reduced motion.
Long lists, such as testimonials and résumé entries, stay on plain white. Blur is costly on low-end phones, and it adds nothing to a long list.
On phones, cards and backgrounds drop the blur.
If a browser does not support blurred backgrounds, or the reader asks for reduced transparency, every surface becomes solid.
Printed pages use plain surfaces with no glow.
The logo is never filtered, tinted or overlaid. Any glow sits on the container behind it.
Glow never replaces the keyboard focus ring.

How we checked that it stays readable

Text on a translucent surface is a moving target. Its contrast depends on what is behind it, and that changes as the page scrolls and as the screen gets wider.

So we did not measure colour pairs in the abstract. We measured the contrast of every piece of text against the background actually rendered behind it, at the brightest and darkest point of that background. We did this at phone and desktop widths on every page we measured. The homepage, the shared header and the shared script were also measured at tablet and ultrawide widths.

We measured every page of the company site, 20 documentation pages drawn from every section of the documentation, all 19 of our pages and blog posts hosted on HubSpot, and a test application page. That came to more than 7,000 measurements of distinct text styles.

Every one met the WCAG AA requirement, which is 4.5 to 1 for body text and 3 to 1 for large text, with three exceptions:

The style guide page contains examples that exist to show low contrast, such as swatch labels and a disabled button.
Some HubSpot forms have a disabled Next button. WCAG exempts inactive controls.
One line of red text on a grey background in the content of our report form. The author set those colours in the page itself, and we have noted it for correction.

The lowest ratio we measured on the shared script was 4.63 to 1. The lowest on the homepage was 4.78 to 1.

There is a limit to this. For each page we measured every distinct text style, with up to four examples of each, and not every paragraph. We did not measure the documentation pages we did not sample, or applications other than our test page. If you find text that is hard to read, please tell us.

Making it easier to start a conversation

These are the homepage changes, and the reason for each.

An availability notice. The hero now states that we are taking on new engagements. A visitor should not have to guess whether we have capacity.
Example projects with rough prices. Each service page lists example projects with estimated prices. They are labelled as estimates, not quotes. Pricing is specific to each client, and the examples exist to help you judge scale before you contact us.
A featured testimonial. One mentee, Rain Kalugdan, describes our mentorship programme in full. We show the whole message, not an excerpt, because the detail is what makes it credible.

A team section. Naomi, Hisho and Tim each have a profile page.
Better phone behaviour. The hero is clearer on small screens. There is a sticky contact button, and each page ends with a contact section.
A newsletter sign-up. It is on the homepage and in the footer.
Confirmation pages. After you submit one of our forms, you now see a page that confirms it and explains what happens next.

Before After

One place for every question

Eight of our pages carried their own FAQ sections. Together they held 88 questions, and many of them repeated across the service pages.

All of them now live in one place. The FAQ page at https://nhcarrigan.com/faq/ answers 62 questions, and each question appears once. Every FAQ section elsewhere on the site shows its questions as cards, and each card links to its answer on that page. Each answer also lists the pages it applies to.

Before After

One header and one footer, everywhere

Every site that loads our shared script now has the same header as the homepage. It carries the same logo and the same links. The text beside the logo is the title of the page you are on.

The footer is a copy of the homepage footer. It has the same columns, the same links, the same address and the same Tree-Nation badge.

The community invitation popup has the same lit surface and rose glow as the rest of the site. The page content sits on a lit, frosted card. Buttons, tables, quotations and code blocks follow the same styling.

Before After Before After Before After

Our forms and our blog are hosted on HubSpot, which uses its own theme. They now load the same script. HubSpot's own header and footer are hidden, and ours are shown in their place.

Why we removed dark mode

We removed dark mode from every site. This is the decision most likely to change how you read our pages, so here is the reasoning.

The homepage never had a dark theme. To make every site look the same as the homepage, we had two options. We could design a second, dark version of every lit surface, every glow and every frosted panel. Or we could drop the toggle.

Light behaves differently on a dark page. The rose light on a dark surface is a glow. On a light surface it is colour bleeding in from a corner. A dark version of the look is not a recolouring. It is a second design, and doing it badly would have been worse than not doing it. We chose one theme, done properly.

There is a cost. Some readers prefer dark pages, and they lose that option on our sites. We know that. We kept the other accommodations: reduced motion, reduced transparency, visible focus rings, and measured contrast.

If the change makes our sites harder for you to read, please tell us at contact@nhcarrigan.com. We would rather hear it than guess.

Before, in dark mode After

The documentation

The documentation at https://docs.nhcarrigan.com has the same changes.

The header carries the same links as the homepage, with the page title beside the logo, and keeps search.
The sidebar, the content and the contents panel sit on frosted surfaces.
Cards, buttons, tables and notes use the same lit surfaces.
The footer is the homepage footer.
The theme picker is gone. Code blocks use the dark code theme, to match the style guide.

Two policy updates were released with it. The Privacy Policy now discloses our newsletter and marketing emails. The change notice dated 14 October 2026 lists the sections affected. The Professional Services and Commission Policy now states that example prices are estimates, and names social media management as a service.

Before After

For developers: version 6 of the shared script

If you build pages that load https://cdn.nhcarrigan.com/headers/index.js, version 6.0.0 is a breaking change.

What was removed

The dark theme, the footer theme toggle and the is-dark class. Nothing adds is-dark any more.
The --page-overlay token.
The old footer element ids.

What is new

A header on every page, unless you exclude it or the page already has its own header.site-header.
A header value for the exclusion attribute.
A data-nhcarrigan-title attribute for the header text.
Opt-in components for cards, notices, quotations, pills, FAQ cards, grids and buttons.

To set the header text:

<html lang="en-GB" data-nhcarrigan-title="Tarot">

If you leave it out, the script takes the page title and removes the NHCarrigan name and its separators. Long titles are cut short with an ellipsis.

To skip the header on a page that has its own:

<html lang="en-GB" data-nhcarrigan-exclude="header">

Every component class starts with nhc-, for example nhc-card and nhc-btn nhc-btn-primary. We prefixed them so that they cannot collide with the styles in your own application.

The semantic variables still exist, and they keep their light values, so existing pages continue to work. The style guide at https://nhcarrigan.com/style/ lists every component, every variable and the full upgrade table. The release notes are at https://github.com/nhcarrigan/website-headers/releases.

What went wrong

We found these problems while building this. We are listing them because they are the useful part.

A dark section turned pale

We wrote a style rule for the light sections. It also matched our dark process section, and replaced its dark background with a pale one. The text became pale on pale, a contrast of about 1 to 1. Measuring found it. It happened a second time when we added a narrow-screen variant of the same rule. We now scope that rule explicitly, and the project documentation records the trap.

The glowing seam stopped short on an ultrawide screen

Each section has a glowing line along its top edge. We had inset it from both sides, which looked like a soft fade on a normal monitor. On an ultrawide monitor it visibly stopped before the edges. It now spans the full width. Our earlier tests had not included a screen that wide.

A background that painted nothing

To stop page content scrolling behind the floating header, we added a strip of frosted artwork behind it. The strip did nothing. A CSS background shorthand allows a plain colour only in its last layer, and we had put one above the image. The browser discarded the entire declaration without a warning. A screenshot showed the fault straight away. Reading the code had not.

Blue text in the HubSpot header

On HubSpot pages, the header title and button rendered in blue. HubSpot's theme styles links with a more specific selector than ours, so theirs won. We raised the specificity of the header and button rules. This would have affected any application with strong link styles, including ones outside HubSpot. HubSpot's theme also colours its links violet, which fell below the 4.5 to 1 requirement on our lit card. We set its link colour variables to ours.

Each of these was found by measuring or by looking at a rendered page. None was found by reading code.

If something looks wrong

If a page looks wrong to you, please send us the address, the size of your screen and a screenshot. Our contact address is contact@nhcarrigan.com.

Thank you for reading.

How I Approach Events Differently

naomi@nhcarrigan.com (Naomi Carrigan) — Mon, 12 Oct 2026 22:49:25 GMT

Most event recaps list what happened. I try to do something different. I treat an event as a set of decisions I make before, during and after, and I check each decision against data.

This post describes three of those habits. They come from two events this year: AI Hackathon @ Berkeley and a developer conference expo in San Jose.

Before the event: every resource gets its own link

Before I run a workshop, I give every resource its own short link: signup, the guide, the docs, each repository, the slide deck and the Discord invite. If I do not, I can only guess what people did after the session.

At Berkeley, I ran a workshop for about 50 people. The tracked signup link recorded 243 signups, close to five times the size of the room. The guide was the second most-used link, with 209 clicks, ahead of the documentation. I write the guide so that it works without me in the room, and the numbers suggest that people used it that way.

The links travelled. They were shared in Discord, placed in repository READMEs and passed around a hackathon of almost 400 projects. A session of 50 people reached several times its own size.

The data also changed my plan. About 74 percent of the repository clicks were for Python, so I now write workshop content for Python first.

During the event: I watch the room and change what I show

A booth is a set of decisions made during the event. Here is how that worked at the expo in San Jose.

The day before the expo opened, I scoped the venue and confirmed our booth space. That gave me time to plan the screen before the first visitor arrived. The booth ran two looping slides. One carried QR codes for Discord, signup and documentation. The other carried a single code for our conference. Every code was a tracked short link, so I could see what visitors actually used.

After about an hour, I replaced the documentation code with a careers code. I made that change because I watched who stopped at the booth. Students kept asking about jobs and internships, and the docs link was not what they wanted. The careers link finished third of five, with around 60 clicks. The documentation link finished last, with about ten. The data confirmed what I had seen.

The audience was mixed: working engineers, students, and founders and technical leads. Founders asked about our startup programme. I run it, so I could answer them directly. I covered the booth for both full days and scanned well over 100 leads myself. Whenever a visitor asked for a demo, the demo took priority over the slides.

Presence matters as much as the screen. At Berkeley, I was the only sponsor who stayed all night, and I wrote about that in I Stayed for 36 Hours Straight. Here Is Why. During those 36 hours, 42 people personally invited me to see their project. Our track was not decided in the two-hour judging window. It was decided over the 24 hours before it, because I had watched the winning team build.

After the event: I read the numbers honestly

I report tracked numbers as floors. At Berkeley, some tables also had generic QR codes that I could not measure, so real engagement was higher. Every untracked code is engagement I cannot count. I also do not stretch a number past what it shows. The careers and internship links had generic codes beside them, so I draw no recruiting conclusion from either.

I keep numbers that answer different questions apart. At the expo, we recorded over 200 link clicks and at least 20 registrations for our conference. Clicks are interactions. Registrations are conversions. I do not call them a funnel until the registration data has been reconciled. In my event report, I leave a field empty when I do not have the data yet. A blank is better than a guess.

The same habit applies to sponsor tracks. I do not judge a track by its submission count. Ours received 141 submissions at Berkeley, third-most of any sponsor. But the event had 398 projects, and each team could enter as many tracks as it liked. A count measures how easy a track was to enter as much as how appealing it was.

So I compare tracks by adoption rate against integration effort. I rate effort on four levels: none, low, medium and high. The track with the most submissions asked teams to build with a coding assistant that most of them already used. Another asked for a backend addition to an app that already existed. Ours needed a new modality. A team had to capture a microphone stream, connect speech-to-text or a voice agent, and handle real-time audio. Our criteria also said that voice must be essential to the experience, not added on. That works as a quality filter.

On that measure, 141 teams, 35 percent of the event, chose to put voice at the core of their project when nothing forced them to. The prize was four games consoles, while other sponsors offered cash, credits or an office hour. Arguably, that is the strongest result on the board.

A track that asks for more has to give more help. That is why I ran a workshop and shared starter repositories in Python and JavaScript for it. When I report a result like this, I give both numbers. The count is real. The adoption rate explains it.

What connects these habits

Each habit answers one question. Before the event: how will I know what happened? During the event: what is the room telling me, and what should I change? After the event: what do the numbers actually show, and what do they not show?

An event is not something I attend and then summarise. It is something I can plan, adjust and measure. That is the difference I try to bring to every event I work.

If you run events for a developer audience, start with one change: give every resource its own link. Everything else follows from being able to see what people did.

How to Spot a Fake Email

naomi@nhcarrigan.com (Naomi Carrigan) — Thu, 08 Oct 2026 01:53:25 GMT

Here’s the thing about phishing emails: the ones that actually catch people are not the obvious, typo-riddled ones with subjects like “URGENT!!! Your account will be DELETED!!!” Those are easy to laugh off. The dangerous ones are polished, they look legitimate, and they come at a moment when you’re distracted or stressed. That’s by design.

So let’s talk about what to look for.

The Sender’s Address Is Where You Start

The display name - the “from” label you see in your inbox - can say anything. “PayPal Support”, “Apple ID Security Team”, your bank’s name. That part is trivially easy to fake and tells you nothing.

What matters is the actual email address. Click or tap on the sender’s name to reveal it. A real email from PayPal comes from @paypal.com. Full stop. Not @paypal-support.net, not @paypal.accounts.info, and definitely not @gmail.com.

Some things to watch for:

The domain doesn’t match the organisation’s website (e.g. support@amazon-billing.com vs amazon.com)
Subtle misspellings - micros0ft.com, arnazon.com - designed to look right at a glance
Long strings of random characters before the @
Free email services for anything claiming to be an official company

Be Suspicious of Generic Greetings

Legitimate companies that hold your account know who you are. They’ll use your name. If an email from your bank opens with “Dear Valued Customer” or “Hello Account Holder”, that’s a signal - they’re sending this to thousands of people and don’t actually have your details.

Urgency Is a Red Flag, Not a Reason to Act

Scammers are in the business of making you panic before you can think clearly. Phrases like these are designed to do exactly that:

“Your account will be permanently closed within 24 hours if you do not verify your details immediately.”

No legitimate company communicates with you this way. If you’re worried the email might be real, go directly to the company’s website by typing the URL yourself - not by clicking anything in the email.

Hover Before You Click

Before clicking any link, hover your mouse over it and look at the destination URL in your browser’s status bar. On mobile, press and hold to preview it.

Ask yourself: does the domain actually match the company? A common trick is to make the real domain look like a subdomain - accounts.microsoft.com.verify.ru looks almost right at a glance, but the actual domain there is verify.ru.

When in doubt, navigate to the company’s website yourself. Type it in. Don’t follow the link.

Unexpected Attachments Are a No

Real organisations rarely send you attachments out of nowhere. If an email you weren’t expecting arrives with a file attached - especially something like .exe, .zip, .doc, or .pdf - don’t open it.

If the email claims to be an invoice or important document, log in to the company’s website directly to find it there. If it’s real, it’ll be in your account.

What to Do If You’re Not Sure

Don’t click anything or open any attachments until you’ve verified the email is legitimate
Contact the company directly using contact details from their official website, not anything in the email
Report it to your email provider’s spam or phishing reporting tool
Delete it

If you did click something before reading this - change your passwords immediately and enable two-factor authentication on any accounts that might be affected.

Everyone can be caught off guard. Scammers are good at what they do, and they put a lot of effort into making things look real. Being cautious is not paranoia - it’s just good practice. When in doubt, don’t click~

How to Ask for Help (And How to Give It)

naomi@nhcarrigan.com (Naomi Carrigan) — Thu, 08 Oct 2026 01:53:22 GMT

Something I’ve noticed after years of running communities and helping people learn: most problems with getting help aren’t about knowledge gaps at all. They’re about communication. Either the person asking hasn’t given enough to work with, or the person helping has jumped straight to the answer and accidentally short-circuited the learning.

Both sides of this are worth understanding. So here are both.

Asking for Help Well

There’s a difference between asking for help and asking someone to do the thing for you. Neither is wrong, exactly, but they produce very different outcomes.

Tell us what you’ve already tried

This is the single most useful thing you can include in a help request. Not just “I’m stuck” or “this isn’t working” - but what did you try? What happened when you tried it? What did you expect to happen instead?

“My code doesn’t work” is not a question. “I expected this function to return a sum, but it’s returning NaN, and I’ve checked that the values are numbers going in” - that’s a question. The second version gives anyone helping you something to actually respond to.

It also forces you to think through what you actually know, which is often where the answer lives.

Give us something minimal and reproducible

If you’re sharing code, please don’t paste your entire 300-line file. Strip it down to the smallest version that still shows the problem. This is useful for you and for the person helping - it removes the noise and makes the actual issue much easier to spot.

I’d say the majority of times I’ve asked someone to do this, they find the problem themselves in the process of making the minimal example. That’s not a coincidence.

Ask about the thing you actually don’t understand

It sounds obvious. It isn’t. A lot of people ask about symptoms rather than the underlying confusion. “Why does JavaScript do this?” is less useful than “I thought variables were always accessible throughout a function - why is x undefined inside this loop?”

The more specific you can be about where your mental model breaks down, the faster someone can help you fix it.

Don’t paste the error and disappear

Share the error message, yes. Also share what line it happened on, what you were doing when it appeared, and any relevant context. An error message without context is just noise. With context, it’s a road map.

Giving Help Well

Now for the other side.

The temptation, when someone asks you a question you know the answer to, is to just… answer it. I get it. It feels efficient. It solves the immediate problem.

The thing is, it doesn’t actually help.

The answer they can find themselves is worth more

When someone works through a problem and reaches the answer through their own reasoning, something clicks that doesn’t happen when you just hand them the solution. They own it. It becomes part of how they think, not just something they copy-pasted.

If you hand someone the answer, they’ll be back with the same question in a different shape next week. If you guide them to it, they probably won’t need to ask again.

The Socratic method works

I’ve written about this before in the context of code specifically, but the principle applies everywhere. Rather than answering directly, ask questions. Start broad, then get narrower as the person gets closer.

The goal is to get them thinking about what they already know that applies here - because usually, they know more than they think.

For something like “how do I find the sum of numbers in an array?”, instead of writing the function for them, try: “How would you do this on paper, without any code?” Almost everyone knows how to add a list of numbers. The answer to that question usually unlocks the rest.

Each question you ask should narrow in, based on where they are. If they’ve understood the logic but are stuck on syntax, ask about syntax. If they don’t yet understand the underlying concept, stay at the concept level a bit longer.

Tell them what to try, not what the answer is

There’s a version of helping that lives in between “here’s the answer” and “ask endless questions”. It looks like: “I’d look at how your variable is being scoped here” or “check what type that value actually is at that point in the function.”

You’re giving them direction without removing the work. They still have to figure out what the scoping issue is, or why the type is unexpected. You’ve just pointed them at the right corner of the room.

Don’t shame people for asking

I’ve seen helpers make people feel embarrassed for asking “basic” questions. It’s counterproductive and unkind. There are no questions that don’t deserve a genuine response. If someone is asking, they’re trying to learn, and that’s a good thing.

The goal of giving help is not to demonstrate what you know. It’s to help the other person understand something. Those are different things.

Learning happens in the space between confusion and understanding. Good questions make that space navigable. Good guidance keeps the learner in the driver’s seat. Both take a bit of practice, but they’re worth developing - you’ll use them constantly, in every community and every project, for the rest of your life~

Optimising Your Token Usage in Claude Code

naomi@nhcarrigan.com (Naomi Carrigan) — Thu, 08 Oct 2026 01:53:21 GMT

I had to write this guide for some colleagues of mine, and decided it was worth sharing more widely because the same handful of habits come up every time I watch someone burn through their usage cap faster than they should.

If you’re on a Pro or Max plan, your budget is generous - but finite. The good news is that most token waste comes from a small set of fixable patterns, and fixing them doesn’t require changing how you fundamentally work with Claude Code. It mostly requires changing a few habits.

Quick Reference

Wasteful Habit	Better Approach
Pasting entire files	Reference by file path
Long-running conversations	Start fresh after each task
Vague requests	Specify the exact file, function, and problem
Asking Claude to explain everything	Only ask when you genuinely need to understand
Re-explaining project context	Use CLAUDE.md
Indexing irrelevant files	Use .claudeignore
Retyping repeated prompts	Create custom slash commands
Opus for everything	Match the model to the task
Confirmation loops	Tell Claude to act; specify constraints upfront
Pasting screenshots of text	Copy the text directly
Asking Claude to summarise what it just did	Look at the changes yourself
Using Claude Code for quick questions	Use claude.ai instead
Multiple related changes as separate messages	Batch them into one prompt
Jumping into a complex task	Use /plan first
Simple one-line edits	Just do it yourself
Extended thinking left on by default	Enable only for genuinely complex reasoning

Understand What’s Actually Costing You

Tokens are consumed by everything in the context window - not just your latest message, but the entire conversation history, every file you’ve pasted, every response Claude has given.

One thing a lot of people don’t realise: output tokens cost roughly three to five times more than input tokens. This means asking Claude for lengthy explanations, verbose generated code, or exhaustive documentation is disproportionately expensive. If you don’t need the explanation, say so upfront. “Make the change, no explanation needed” saves more than you might expect.

The single biggest lever you have is context window size. A bloated conversation is the most common cause of hitting limits early.

Start Fresh Conversations Aggressively

This is probably the most impactful single change you can make. After a task is complete, that conversation history is dead weight. If you’re starting a new task - even a loosely related one - open a new conversation.

Signs you should start fresh:

The task is different from what you were just doing
You’ve been in the same conversation for over an hour
Claude has already completed what you asked and you’re moving on

In Claude Code, use /clear to reset the context without closing the session.

Don’t Paste Files - Let Claude Read Them

A very common pattern:

“Here’s my code: [pastes 400 lines]… can you fix the bug in the validateUser function?”

This is expensive. Claude Code can read files directly from your filesystem. Instead:

“Fix the bug in the validateUser function in src/auth/validator.ts.”

Claude will read exactly what it needs. You save hundreds or thousands of tokens per interaction.

The rule: if the file exists on disk, reference it by path. Never paste unless Claude explicitly cannot access it.

You can also type # in the Claude Code prompt to attach a specific file directly to the conversation - more precise than asking Claude to go find something on its own.

Be Specific From the Start

Vague requests lead to expensive back-and-forth. Every clarifying message adds to the context. Front-load the specifics:

Instead of:

“Can you help me with my authentication system?”

Try:

“The refreshToken endpoint in src/routes/auth.ts is returning a 401 on valid tokens. The token validation logic lives in src/middleware/auth.ts. Please diagnose and fix the issue.”

One well-specified message replaces three or four vague ones.

It is also worth being explicit about what not to touch:

“Only change the render method. Do not modify the props interface or the styles.”

This prevents unwanted refactoring and saves the correction turns that follow it.

Ask for Exactly What You Need

Some phrases generate unnecessary tokens:

“Can you explain what you just did?” - skip this unless you genuinely need to understand it
“What do you think about…” - open-ended questions invite long responses
“Walk me through your reasoning” - only ask when the reasoning matters to you

Some phrases that keep responses tight:

“Fix X in Y” - just do it, no explanation needed
“List only the changed files”
“Give me the updated function only, not the full file”

And - don’t ask Claude to summarise what it just did. The changes are right there in your editor. Reading them yourself is free.

Use CLAUDE.md for Persistent Context

If you find yourself re-explaining the same things at the start of every conversation - your project structure, your coding standards, your preferred tools - you’re wasting tokens every single time.

CLAUDE.md files solve this. Claude Code reads them automatically at the start of each session. Create one in your project root with:

Tech stack and architecture overview
Key file locations
Standards and conventions
Anything you’d otherwise have to re-explain

Keep it lean. Every line is read at the start of every session. A bloated CLAUDE.md costs you tokens before you’ve typed a single message. Include only what Claude genuinely needs - and review it occasionally to remove anything that has gone stale.

Break Large Tasks Into Focused Sub-Tasks

Large tasks generate large context, large responses, and more opportunities for misunderstanding that requires correction.

Better approach:

“Audit src/components/ and list every component that’s missing prop validation.” - small, focused
Review the list, pick the ones you want fixed
“Add prop validation to the components in src/components/forms/.” - targeted fix

Each conversation stays lean. You only spend tokens on what you actually need.

Avoid Confirmation Loops

A surprisingly common pattern:

You: “Can you update the button styles?” Claude: “Sure! I’ll update the button styles by modifying the CSS to…” You: “Yes, go ahead.” Claude: [does the thing]

That middle exchange cost you tokens and time. Claude Code is an agent - you can just tell it to do things. If you have concerns about scope, be explicit upfront: “Update the button styles - check with me before touching anything outside src/styles/buttons.css.”

Compact Long Conversations

When you want to continue work rather than start fresh, use /compact in Claude Code. This summarises the conversation history into a condensed form, freeing up context window space whilst preserving the key information.

Use this when:

You’re mid-task and can’t start fresh
The conversation is getting slow or hitting context limits
You’ve completed several sub-tasks and want to continue

Choose the Right Model for the Task

Claude Opus is powerful but expensive. Claude Sonnet is the sweet spot for most development work. Claude Haiku is excellent for simple, high-volume tasks.

If your plan gives you model selection, use it deliberately:

Haiku: boilerplate generation, simple refactors, quick lookups
Sonnet: most coding tasks, debugging, code review
Opus: genuinely complex architecture decisions, nuanced analysis

Using Opus for everything is like driving a lorry to pick up groceries. It gets the job done, but it’s not the right tool.

Use .claudeignore to Exclude Irrelevant Files

When Claude Code starts a session, it indexes your project. If your repository contains large generated directories, build artefacts, or vendor files, Claude is spending context on things it will never need to touch.

Create a .claudeignore file in your project root using the same syntax as .gitignore:

node_modules/
dist/
build/
.next/
coverage/
*.log

Create Custom Slash Commands for Repeated Workflows

If you find yourself typing the same prompt over and over - running a code review, generating a specific type of test, writing a commit message - turn it into a custom slash command.

Custom commands live in .claude/commands/ in your project (or ~/.claude/commands/ for global commands available in every project). Each command is a markdown file where the filename becomes the command name. .claude/commands/review.md becomes /review.

This ensures consistent, well-structured prompts every time - no more accidentally leaving out key context because you were typing from memory.

Don’t Paste Screenshots When Text Will Do

Images are token-heavy. Pasting a screenshot of an error message, a terminal output, or a UI bug costs significantly more than just copying the text.

Screenshots are genuinely useful for visual layout bugs, design feedback, or anything where the visual content itself is the point. For error messages, terminal output, and code - just paste the text. If you could copy-paste it, do that instead.

Use the Right Interface for the Task

Claude Code is a powerful agentic tool. That power comes with overhead. Loading it up to ask a quick question is like starting a car to walk to the end of the driveway.

Use claude.ai for:

Quick questions (“what does this regex do?”, “explain this algorithm”)
Brainstorming and ideation
Drafting text or documentation without file context
Anything where you’d just be typing a question and reading an answer

Use Claude Code for:

Anything that requires reading, writing, or editing files
Debugging with access to your actual codebase
Multi-step agentic tasks
Anything that benefits from your project’s CLAUDE.md context

Keeping this distinction in mind means your Claude Code sessions stay focused on work that genuinely needs them.

Batch Related Changes Into One Request

One request that makes five related edits is far cheaper than five separate requests.

Instead of:

“Rename getUserById to fetchUser.” “Now update the call in the controller.” “Now update the call in the tests.”

Try:

“Rename getUserById to fetchUser everywhere - the function definition in src/db/users.ts, its calls in src/controllers/userController.ts, and its usage in test/users.spec.ts.”

Each separate message carries the full conversation history as overhead. Batching related changes keeps the context window lean.

Use Plan Mode for Complex Tasks

Before Claude starts making changes on a large or uncertain task, use /plan to have it outline its approach first. Reviewing a plan is cheap. Undoing a series of incorrect edits is expensive.

This is especially useful for refactors that touch many files, new features where the architecture isn’t obvious, or anything where you want to validate the approach before changes are made.

Know When Not to Use Claude

Just do these yourself:

Changing a single string or variable name in one place
Adding a single line of code you already know
Fixing an obvious typo

Use your editor’s search for these:

Finding where a function is defined
Finding all usages of a variable
Checking which files import a module

Ctrl+Shift+F or Cmd+Shift+F is instant and free. Save Claude for work that genuinely benefits from AI reasoning.

Use Git to Recover, Not Claude

If Claude makes a change you didn’t want, reach for git rather than asking Claude to undo it:

git restore src/path/to/file.ts

This is instant, free, and precise. Asking Claude to revert its own changes costs tokens and risks introducing new problems. Once the file is restored, re-prompt with a more specific instruction.

Advanced Techniques

The tips above will eliminate most waste. These are for when you have the basics down and want to go further.

Understand the CLAUDE.md Hierarchy

CLAUDE.md files are inherited, and Claude Code reads multiple levels:

~/.claude/CLAUDE.md - user-level, applies to every project on your machine
/your-project/CLAUDE.md - project-level, applies to that project
/your-project/src/CLAUDE.md - subdirectory-level, applies when working in that folder

Put genuinely universal preferences at the user level. Put project-specific context at the project level. Most people only use the project-level file and end up duplicating preferences across every project - centralising shared context at the user level means you write it once.

Use Subagents for Parallel, Independent Tasks

Claude Code can spawn subagents - separate instances that each handle a focused task with their own clean context window. Instead of doing three things sequentially in one growing conversation, three subagents can work in parallel, each staying lean and focused.

This is especially powerful for independent tasks:

“Audit the API routes for missing input validation, audit the database queries for missing error handling, and audit the frontend components for missing loading states - run these in parallel.”

Each subagent handles one audit without the others polluting its context.

Discipline Your Output Format

Every word Claude writes costs tokens. When you only need a specific piece of output, ask for exactly that:

“Return only the updated function, not the full file”
“List the affected files as a bullet list, nothing else”
“Respond with JSON only, no explanation”
“Give me a one-line summary”

Use Skills for Complex Repeated Workflows

For multi-step workflows that go beyond a single prompt, Claude Code supports skills - reusable sequences of instructions that can span multiple steps, use tools, and handle conditional logic.

Skills live in ~/.claude/skills/ and are documented in a SKILL.md file. Well-written skills pay enormous dividends for workflows you run repeatedly.

Extend Claude with MCP Servers

MCP (Model Context Protocol) servers give Claude direct access to external systems - databases, APIs, project management tools, documentation, and more. When Claude can query a system directly, you stop needing to paste data in from it.

Without an MCP server:

“Here’s the current database schema: [pastes 200 lines]… can you write a migration?”

With an MCP server:

“Write a migration based on the current schema.”

Claude fetches what it needs directly. This eliminates an entire category of token waste for teams that regularly work against external systems.

Understand How Caching Works

Claude Code automatically caches stable context - your CLAUDE.md, system prompts, and other content that doesn’t change between turns. Cached tokens consume roughly 10% of your compute budget compared to fresh tokens.

What this means in practice:

The cache has a 5-minute TTL. If you step away for more than five minutes and come back, your next message pays full price. Use /compact before stepping away rather than leaving a context-heavy session idle.
Don’t modify your CLAUDE.md mid-session. Every change invalidates the cache for that content. Make CLAUDE.md changes between sessions, not during them.
Short, frequent interactions benefit more than long, sparse ones. Staying engaged within the TTL window means your stable context stays cached across multiple turns.

Use Extended Thinking Sparingly

Extended thinking is the right tool for complex architectural decisions, subtle debugging where the cause isn’t obvious, and problems that genuinely require multi-step reasoning.

It is not the right tool for routine code generation, simple refactors, or any task where a direct answer is clearly possible. If you’re hitting your limits faster than expected and extended thinking is enabled, try disabling it and see how much of a difference it makes.

Automate Repetitive Setup with Hooks

Hooks are scripts that Claude Code runs automatically in response to specific events - before or after a file edit, after a bash command, before a session ends, and so on.

A hook that automatically runs your linter after every file edit means you never have to type “run the linter” - Claude just handles it. Hooks are configured in your Claude Code settings. Start with one hook for your most repeated manual step and go from there.

Pre-approve Trusted Tools to Avoid Interruptions

Every time Claude needs to run a command or use a tool you haven’t pre-approved, it pauses and waits. In a long task, repeated approval prompts break flow - and sometimes cause Claude to lose track of what it was doing, requiring a recovery turn.

In Claude Code settings, you can pre-approve tools and shell commands you trust. If you always want Claude to be able to run your test suite or your linter without asking, add those permissions once and never be interrupted for them again.

If you have questions or suggestions, feel free to come find me~

The 'Help Me Debug My Repo' NPM Scam

naomi@nhcarrigan.com (Naomi Carrigan) — Thu, 08 Oct 2026 01:53:20 GMT

This scam is particularly clever because it exploits something genuinely good about developers: we like helping each other.

Someone reaches out and asks you to take a look at their repository. Maybe they need help debugging something, maybe they’re asking for a code review. The repo looks like a real project. You clone it, you run npm install, and that’s it - you’re already compromised.

What Actually Happens

The malicious npm package in the repository contains a post-install script. NPM runs these automatically when you install dependencies. You never had to run their code explicitly, never had to open a file, never had to do anything except type npm install.

The script reads your browser’s local cache and extracts stored credentials - including your Discord token - and sends them to the attacker. With your Discord token, they have full access to your account.

Why This Works So Well

The reason this scam catches people who really do know better comes down to a few things.

You’re trying to help. The request isn’t suspicious on its face. Someone needs debugging help, and you’re a decent person who helps people with code. Nothing about that set of circumstances triggers alarm bells.

Most people’s mental model of “running untrusted code” is wrong. The common advice is “don’t run untrusted executables.” But npm install is running code. It executes scripts from every package in the dependency tree, automatically, as part of the install process. If any of those packages is malicious, you’re done.

The repository can look entirely legitimate. Sensible directory structure, a readme, some commit history. Nothing in the code itself is obviously wrong.

The Full Picture of What “Running Code” Means

When you interact with someone else’s project, here’s a more complete picture of what actually executes:

npm install - runs post-install scripts from every package in the dependency tree
npm run <anything> - obviously executes code
Build tools like webpack or vite - their config files are executable JavaScript
Some IDE extensions - these can run things automatically when you open a project

The rule I’d suggest: if you do not know where the code came from and cannot verify it, treat the whole thing as potentially hostile - including the install step.

If You Want to Help Anyway

There are safer ways to review someone’s code without putting yourself at risk:

Read the code before you run anything. Check package.json - specifically the scripts section and the dependency list. Look up anything unfamiliar on npmjs.com before installing it.
Use a sandboxed environment. A VM, a container, or a disposable environment you don’t mind wiping if something goes wrong.
Ask yourself why they’re contacting you. Legitimate collaboration requests usually happen in context - through an existing relationship, in a community channel, with some shared history. Out-of-nowhere DMs asking you to run their code are a pattern worth questioning.

If You Think You’ve Already Been Caught

If you ran npm install on a suspicious repository and you’re worried:

Change your Discord password immediately - this invalidates existing tokens
Log out of all devices - go to User Settings > Devices in Discord
Check your account for any messages you did not send
Rotate other credentials that might have been stored in your browser
Enable 2FA on Discord if you haven’t already

This one is a good reminder that security isn’t just about what you actively run - it extends to every step of setting up and working with code.

Common Discord Scams to Watch Out For

naomi@nhcarrigan.com (Naomi Carrigan) — Thu, 08 Oct 2026 01:53:19 GMT

I run a lot of communities on Discord. Which means I see the same scams come through, over and over, in different servers, in different forms, like some kind of horrible recurring nightmare. Compromised accounts spread these things fast - once one person gets caught, their account immediately starts messaging everyone they know.

So here’s a rundown of the ones I see most often, and what you should know about each.

Nitro Scams

The most common one, and self-propagating. Someone - usually a victim of the same scam - sends you a “free Nitro” link, either in a DM or dropped into multiple channels at once.

These links use URL hijacking: they look like legitimate Discord domains, but they are not. If you click through and “log in”, you have just handed the attacker your account token. Your account then starts sending the same message to everyone you know.

I’d say the giveaway is the urgency and the fact that it arrived out of nowhere - but honestly, the links are often convincing enough that people who know better still click. The best defence is simply: free Nitro offers in DMs are always scams. Every single time.

”Try My Game” Scams

Someone asks you to play-test their game. The game is usually hosted on itch.io and looks like a real project.

When you download and run it, the executable reads your Discord client’s local data and extracts your token. The attacker now has your account and uses it to continue spreading the same messages.

Don’t download games from strangers on Discord. That’s the whole rule.

Steam Report Scam

You get a DM from someone claiming they accidentally reported you to Steam, and that you need to speak with their friend who “works at Valve” to sort it out.

They did not report you. Their friend does not work at Valve. This is social engineering - they want you to follow a link or hand over account information. Steam does not resolve disputes over Discord DMs, and Valve employees do not work this way.

Ignore it and move on.

Fake Discord Official Announcement Scams

You get a DM from an account that looks like it is from Discord - it mentions a beta test, the moderator programme, HypeSquad events, or something similarly official-sounding, with a link to a form to apply.

This is not legitimate, even if the message includes a link to a real Discord server. Real system messages from Discord come through a special account with a system badge, not a regular user account. If there is no system badge, it is not Discord.

QR Code Scams

You join a server and it tells you to scan a QR code with your Discord mobile app to verify or unlock access.

Do not scan it.

The only legitimate QR code you should ever scan with the Discord app is the one on the official discord.com/login page (and watch the URL carefully there too) or within the Discord desktop app itself. Any third-party use of this is a scam. Scanning a malicious QR code logs the attacker into your account from their device.

I see this one a lot targeted at NSFW servers and job-related servers, where people feel more urgency or more reason to trust an extra verification step.

Small Text Markdown Exploit

Discord added a small text markdown feature that took scammers approximately two seconds to start abusing. The technique lets them hide fake instructions or misleading fine print in messages.

One thing worth knowing: in legitimate use, the Dismiss message option in an ephemeral bot response is never a link to anywhere. It just clears the message. If you see small text that contains a link formatted like a dismiss button, that is a red flag.

General Advice

The best defence against all of these is not a verification bot or an anti-phishing tool. It’s basic internet habits:

Don’t click unfamiliar links, even from people you trust - their account may be compromised
Don’t sign in to websites you do not recognise
Always check the full URL before entering any credentials
Use a password manager - most of them will not autofill credentials on the wrong site, which catches spoofed login pages automatically
If you see a server invite being spammed across multiple channels, there’s a very good chance that server is not safe - don’t join it

And if someone in a server you’re in sends you something suspicious, let a moderator know. We’d rather investigate a false alarm than miss a compromised account that then messages another two hundred people.

Stay safe out there~

Spotting Fake Job Post Scams

naomi@nhcarrigan.com (Naomi Carrigan) — Thu, 08 Oct 2026 01:53:18 GMT

Someone I know nearly fell for one of these. They’re a smart, experienced person who knows better - and it almost got them anyway. That’s the thing about fake LinkedIn job posts: they work precisely because they target you at your most vulnerable. You want the offer to be real, so your guard comes down.

Let’s talk about how to tell whether it is.

Step One: Does the Email Come From the Right Domain?

A real email from a company should come from that company’s domain. If the company is NaomiCorp and their website is naomicorp.com, an email from naomicorp@gmail.com or careers@naomicorp.org is a red flag - those domains don’t match.

I know this sounds obvious. But when you’re excited about a job opportunity, it’s easy to notice the company name and not look closely at what follows the @.

Step Two: Check the Email Headers

Even an email address that looks right can be spoofed. The real test is in the headers.

Most email clients let you view the raw message. In Gmail, click the three-dot menu on a message and choose Show original. In Outlook, go to File > Properties and look under Internet headers. You’re looking for something like this:

ARC-Authentication-Results: i=1; mx.google.com;
       dkim=pass header.i=@nhcarrigan.com header.s=mail header.b="P0TRq/Qy";
       spf=pass (google.com: domain of naomi@nhcarrigan.com designates 128.199.1.98 as permitted sender)

Both dkim and spf should say pass. If either says fail, the email may be spoofed.

What is SPF?

SPF stands for Sender Policy Framework. It is a DNS record that lets a domain owner specify which mail servers are allowed to send email on their behalf.

When you receive an email claiming to be from naomicorp.com, the receiving server checks the SPF record for that domain and confirms whether the email actually came from an authorised server. If it didn’t, SPF fails.

You can check a domain’s SPF record yourself - run dig TXT nhcarrigan.com +short in your terminal and look for the v=spf1 entry.

What is DKIM?

DKIM stands for DomainKeys Identified Mail. It is a cryptographic signature that proves the email has not been tampered with in transit.

It works in two parts:

A DKIM record in the domain’s DNS (you can look one up yourself with dig TXT mail._domainkey.nhcarrigan.com +short)
A DKIM-Signature header inside the email itself

The receiving mail server uses the DNS record to verify the signature in the header. If the signatures match, the email arrived intact. If they do not, it may have been tampered with.

What is DMARC?

DMARC is the enforcement layer. A domain owner uses a DMARC policy to specify what should happen when an email fails SPF or DKIM checks: do nothing, route it to spam, or reject it outright.

It is not foolproof - some domains do not have a DMARC policy configured, or have it set to “do nothing” - but combined with SPF and DKIM, it is a meaningful signal.

The Red Flags That Actually Matter

Even if the authentication checks pass, watch for these patterns:

They always want to hire you. Legitimate recruitment involves screening, interviews, and - yes - rejection. If a “recruiter” seems keen to hire you immediately with no real process, their goal is your personal information or your money, not your skills.

They want you to pay for something. No legitimate employer requires you to pay for training, equipment, or onboarding. If money flows from you to them before you have even started, it’s a scam.

They want to send you a cheque. This is the classic overpayment scam - they send you a cheque for more than agreed, ask you to cash it and wire back the difference, and then the cheque bounces. You are out the wired funds and they are long gone.

It feels too good to be true. If the salary is unusually high, the role seems perfectly tailored to your CV, and there is pressure to accept quickly - slow down. That urgency is deliberate.

What to Do If You Are Not Sure

Do not respond or click any links until you have verified the offer is legitimate
Find the company’s official contact independently - look up their real website and reach out through a contact form or email address you found yourself, not one from the message
Check whether the company has a Discord or community space - you can often verify directly with current employees
Ask a trusted technical friend to look at the headers with you

Anyone can be caught off guard by a well-crafted scam, especially when they’re under the stress of a job search. It very nearly happened to me, and I work in tech and know what to look for. Knowing the signs doesn’t make you immune - but it does mean you’re much less likely to be caught out.

Stay safe out there~

Security Incident Report: Compromise of Self-Hosted Gitea and Plausible

naomi@nhcarrigan.com (Naomi Carrigan) — Wed, 07 Oct 2026 03:12:42 GMT

Incident reference: 2026-10-breach. Status: contained and closed. All times are Pacific Time (UTC-7) unless stated.

Summary

On 6 October 2026 we confirmed that two self-hosted services on our production server had been compromised through publicly disclosed vulnerabilities that we had not yet patched: Gitea, which hosted our source code, and Plausible Community Edition, which provided website analytics. Attackers used both to run cryptocurrency miners (XMRig, mining Monero) on our server.

We found no evidence that the server itself was taken over, no implants still running, and no evidence that data was copied off the server. Both services have been permanently decommissioned, our code now lives on GitHub, and we have hardened the server.

Detected: 6 October 2026.
Earliest malicious activity: 30 August 2026 (Gitea, an exploit-confirmation scan), 16 September 2026 (Plausible).
Impact: unauthorised code execution inside two containers, resource theft (mining), and exposure of the secrets those services held.
Not found: evidence of root-level access, credential-stealing code, staged data or misuse of our mail account.

What was affected

Service	What happened	Status
Gitea (code hosting)	Exploited through CVE-2026-59774 (GHSA-6v53-hr58-556r), an unauthenticated file-read flaw that leads to remote code execution. A scanner confirmed the weakness on 30 August. A cryptominer operator took over on 28 and 29 September, and a miner ran from 30 September until we stopped the service on 6 October.	Compromised. Decommissioned.
Plausible CE v3.1.0 (analytics)	Exploited through CVE-2026-8467 (GHSA-mhcv-h7gf-57cf), an unauthenticated remote code execution flaw in the `/storybook` endpoint, fixed in version 3.2.1. Miners ran from at least 16 September.	Compromised. Decommissioned.
The production server	No evidence of root-level compromise.	Hardened. Further updates in progress.
Our other self-hosted services	No evidence of compromise. Several (including our forum, task tracker, file host and translation service) were retired as a precaution.	Retired or being reviewed.

Timeline

When	What
3 June	Plausible publishes a critical advisory (fixed in 3.2.1). We were running 3.1.0.
2 August	Gitea publishes the file-read advisory (fixed in 1.27.1).
30 August	A scanner injects a hook into one repository on our Gitea. It writes a marker file and makes a DNS callback to confirm the server is exploitable.
16 September	Earliest evidence of attacker code running in our Plausible container.
22 September to 6 October	About 580 probe requests to the vulnerable Plausible endpoint, all answered until the service was stopped.
28 September, 19:30	First request in our retained logs from the Gitea attacker. The first full exploit round follows at 21:11.
29 September, 03:31	The attacker installs a malicious setting in Gitea's global git configuration.
30 September	A miner starts (09:33). From 1 October a supervisor process keeps it running.
6 October, 11:43	We stop Gitea after an update leaves it failing to start.
6 October, 12:04 to 13:43	We restart Gitea while troubleshooting. Git fetches begin timing out after exactly 60 seconds.
6 October, about 13:40	We identify the malicious hook as the cause of the timeouts.
6 October, 13:43	Containment: Gitea is stopped again and outbound traffic to the known attacker addresses is blocked.
6 October, 13:45 to 15:05	We capture evidence from the Plausible container, then remove it.
6 October, evening	Binary analysis in an isolated sandbox, a host-wide sweep for leftovers, cleanup, and a final verification at about 20:00.

How the attacks worked

Gitea

The flaw let an anonymous visitor read arbitrary files from the server through the repository markup renderer. The attacker used it to read Gitea's configuration, including an internal API token. That token let them call an internal logging endpoint, which they abused to plant a global git setting (uploadpack.packObjectsHook) pointing at a shell script. From then on, every git fetch or clone against the server ran their script.

The script downloaded a second-stage installer and a bot, which started and supervised XMRig miners. The miners connected to public Monero pools over TLS. The bot could also have installed persistence on the host, but we found no sign that it did.

Plausible

The vulnerable endpoint allowed anonymous remote code execution inside the Plausible container. The attacker started two miners as children of the application process.

How we found it

After updating Gitea on 6 October, git pull against it kept failing: the first request succeeded and the next one hung for exactly 60 seconds, which is our proxy timeout. A process listing during one of those hangs showed the fetch running through a script that did not belong there, and reading that script showed it was a dropper.

What we know about data exposure

Proven: the attacker held Gitea's internal token and could run commands inside the Gitea container as its service account, with access to everything in its data directory (database, configuration, repositories).
The file read itself: about 6.5 KB was returned in total, so it was not used to copy data in bulk. The files read were most likely the configuration file.
Binary and script analysis: we analysed all four binaries and the installer in an isolated sandbox. The miners are stock XMRig. We found no credential-harvesting, archiving or upload logic in any of them, and none in the installer (moderate confidence).
No staged data: no archives or dumps were found in the containers or on the host, and no unexplained outbound connections appeared in the snapshots we took.
Mail: the account that Gitea used to send email logged in from our own server only, with no sign of misuse.
Limits: we have no network flow logs, our web logs only reached back to 22 September, and the period from 30 August to 6 September is not covered by retained mail logs. Absence of evidence is therefore weaker than we would like.

What this means for you: if you had an account on our Gitea (git.nhcarrigan.com), assume its username, email address, password hash, two-factor secret and any access tokens were exposed. If you reused that password anywhere else, change it. The service no longer exists.

What we did

Stopped the affected services, blocked the attacker addresses (now a persistent firewall rule) and preserved the evidence.
Analysed the binaries and scripts in an isolated sandbox, then verified the evidence bundle and moved it to cold storage.
Swept the host for leftovers: no attacker files outside the evidence folders, no live connections to any attacker address, no unexpected persistence.
Decommissioned Gitea and Plausible and removed their data directories, along with the root-level runners that depended on Gitea.
Moved our repositories to GitHub as clean mirrors (server-side hooks and configuration were not copied), and scrubbed the secrets that scanning found in the history of the repositories that had them.
Removed an over-broad passwordless sudo rule, restored correct ownership on our web server configuration, and restarted a monitoring service that had been leaking memory.

Root cause and contributing factors

Unpatched, internet-facing software. Both flaws were publicly documented weeks or months before they were used against us, and our update process did not catch them.
Services published directly through Docker. Docker's port publishing bypassed the host firewall, so several services were reachable without going through our web server.
Too much shared privilege. The services ran under the same user ID as our other applications.
Thin logging. Fourteen days of web logs and no outbound network logging limited what we could prove.

What we are doing next

Applying the pending operating-system updates and rebooting the server onto the current kernel.
Keeping logs longer and shipping them off the server, including outbound connection logs.

Indicators of compromise

We are sharing these so that others running similar software can check themselves. None of the addresses were contacted during our investigation.

Addresses (outbound traffic to all six is now blocked): the first four are attacker infrastructure (download hosts and command servers). The last two are miner endpoints that our Plausible container was connected to.

38.127.244.12
162.4.173.102
80.87.206.86
85.137.54.178
103.189.234.47
45.77.67.39

Git configuration: any uploadpack.packObjectsHook entry in a global git config that points at a script, in particular sh /data/gitea/home/.pwn.

Files and names: .pwn, .ext4402, .boat_landed, ksoftirqd (outside the kernel thread list), linuxsys, syslog-ng-ee175527, /var/tmp/.syslog-*, .upd_boat, the abstract socket boat_mutex_v4, and the bot string boatnet-unit-v2. Marker file /tmp/CVE-2026-59774.proof and DNS callbacks to oob.smartdnslog[.]com belong to the earlier scanner.

Request patterns: POST /{owner}/{repo}/markup with an Org-mode include directive, calls to /api/internal/manager/add-logger, and GET /storybook/iframe/button requests carrying topic=pwn.

SHA-256:

File	SHA-256
linuxsys (XMRig)	`4d17d32ed6efe92ea61d16602f9c6cd5261cdd3820adec427ee68d4088b6ab5b`
syslog-ng-ee175527 (XMRig)	`b20f39fc00d242e706b6c30367ad811c676e0575050a4ec2f30104b696944b49`
Stage-2 installer (`/i`)	`fb3c23572dfd971ac52dd7991373631978b2107c8f2fa4348f87924d7d834dd8`
ksoftirqd (XMRig), prefix only	`315217b58357...`
.ext4402 (bot), prefix only	`676149d53fe8...`

How confident are we?

We are confident about the Gitea findings and timeline, and confident that the server itself was not breached and that nothing was exfiltrated. The main gaps are the command channel the bot used (we saw the addresses but never the traffic), earlier versions of the attacker's script that were overwritten, and the unlogged period from 30 August to 6 September. If we learn anything that changes these conclusions, we will update this post.

References

I Stayed for 36 Hours Straight. Here Is Why

naomi@nhcarrigan.com (Naomi Carrigan) — Wed, 24 Jun 2026 12:00:00 GMT

I attended AI Hackathon @ Berkeley 2026 representing Deepgram, and I did not sleep. I did not have to stay awake. I could not bring myself to leave.

I was there for all of it: the sponsor booth, the workshop, the judging and the full 36 hours. I want to be direct about why. The reason was the people. The hackers at Berkeley were some of the most enthusiastic builders I have been around. They were not only building. They wanted to talk, and they wanted to show me what they were making. They had questions at 2am, at 4am and at 6am, and they did not care what time it was.

That is not an energy I could walk away from.

What We Were There For

Deepgram sponsored the Best Use of Deepgram track. The track asked teams to build real-time voice into their projects as an essential part, not an afterthought. Out of 398 total projects, 141 teams did this. That is 35% of the hackathon building voice-first.

I knew beforehand that voice is a difficult integration. It cannot simply be added at the end. Even so, team after team came to our booth. They told me what they were building, how they were using the API, what was working and where they were stuck. I had those conversations all night.

No metric captures one part of this: the look on someone's face when their real-time transcription works for the first time.

How I Showed Up

I think much of why this event felt different came from a choice I made before I arrived. I decided to do more than is usual for a sponsor.

We set up a monitor at the booth with QR codes. I ran a workshop. I was the only sponsor who stayed all night.

While everyone else went home, I stayed. At 2am, people were doing push-ups in the aisles to stay awake. By 6am, there were hackers asleep on the floor next to my booth. I was still standing, so I was still having conversations. They were real conversations about what people were building, what was working, what they were stuck on and what they wanted to do next.

Two figures reflect this. There were 243 workshop signups from a room of 50 people. There were 42 people who personally invited me to see their project in our sponsor Slack channel. Both followed from my being present throughout the event.

Judging

There were 141 submissions in our track and a two-hour judging window. I walked the floor and visited as many as I could of the teams that had contacted me personally. While I walked, other teams saw me and called me over to their tables. The whole floor was in motion.

When the window closed and I submitted my winner, people began lining up at the booth. For another 90 minutes, team after team came to show me what they had built with Deepgram and to talk about what came next. No one was aggressive. Everyone was polite. They wanted to talk about the API, their project and where it was going. That is rare at a sponsored event.

The team behind aside.ai won our track. The reason was not the two-hour judging window. It was the 24 hours before it. They had been in conversation with me for the entire event. They showed me their work, iterated and checked back in. By the time I submitted the winner, I had watched them build the project.

The Projects

The range of what people built was very wide. I want to be specific about that. Every hackathon recap mentions a variety of projects, and most do not mean it in the way I mean it.

voxaid is a speech pipeline fine-tuned for dysarthric speech. It is intended for people with ALS, cerebral palsy and stroke, whose voices existing recognition software does not understand. The team fine-tuned a wav2vec2 model on the TORGO dysarthric speech dataset. They used an architecture from a paper published two days before the hackathon started. They then passed the output through Claude for semantic reconstruction and Deepgram Aura for voice response. The result was a full speech-to-speech system that could take unclear input and produce natural output. It is intended for people who currently depend on a human interpreter to communicate. It was built at a hackathon.

aintercept is a scam interception tool. It listens on a call and alerts someone as soon as it detects the patterns of a scam in progress. The builder's grandmother had fallen for a fake police officer scam the year before. They explained to me exactly what had happened, and then they showed me what they had built. Those two conversations were about thirty seconds apart.

crisisroom was built by a veteran who served on a landing ship in Singapore. He described damage control at sea. There is a steel passageway with strobing lights and smoke filling the space. Water rises past your boots. A general alarm is so loud that you cannot hear the person next to you. A grease pencil on a plexiglass board is the only shared source of truth for everyone making life-or-death decisions. He built a real-time, voice-powered incident response system because he had lived with the cost of not having one. The problem statement he gave me at the booth was one of the most striking things I heard all weekend.

moggie is a portable party-game kiosk running on a Raspberry Pi. Players compete in facial expression matching and hand-motion challenges, with Deepgram powering the social and voice layer. It was built as a response to looksmaxxing culture. The hypothesis is that if people laugh and compete together in person over topics they would otherwise obsess over alone, something changes. It was also chaotic and enjoyable, to the point that I forgot I was 18 hours into a hackathon.

séance lets you point your phone at any object. The object becomes a character and talks back to you. You can argue with your water bottle, or have a stapler answer back. I will not claim this solved a critical global problem. It was one of the most enjoyable things I saw all weekend, and the group of people around it was always laughing.

The last project was aside.ai.

The team behind aside.ai won our track and deserved to. Their project was a clip-on wearable. A Raspberry Pi camera streamed frames over Wi-Fi to a laptop. The laptop used Claude for vision and Deepgram for both speech-to-text and text-to-speech. It narrated the world around the wearer in real time, in a personality of their choice, such as a hype man, a goth therapist or an epic quest narrator. The same moment was described differently depending on the personality chosen. The project was technically strong and funny, and the team had clearly thought hard about both.

What stayed with me about aside.ai was not only the project but the team. They were at my booth constantly. They were not asking for help. They were showing me things and iterating. At one point I noticed that the booth next to mine had been empty for the entire event. Someone from their team was now sitting there, editing and publishing social media content in real time to build interest in what they were making. They had not only built a startup. They had shipped a startup. At a hackathon.

The Workshop

We ran a workshop during the event with about 50 people in the room. The links we handed out produced 243 console signups. That is nearly five times the number of people who were physically present. The resources spread across the whole 398-project event, and I watched it happen in real time from the booth. Links appeared in Discord servers, were added to READMEs and were passed between teams who had never attended the session.

What I Am Taking Away

I have been to many events. Berkeley felt different. The students there were not only looking for a prize. They were building things they were excited about, and they wanted to talk to the people behind the tools they were using. That is rare.

I stayed for 36 hours because the room kept giving me reasons to stay. I would do it again without hesitation.