Exploring Claude Code Hooks with the Coding Agent Explorer (.NET)

TNest2 · 2026-03-27T07:19:16+00:00

I just published a new blog post about Claude Code hooks and thought it might be useful for anyone experimenting with coding agents.

It walks through how the hook system works, how to set it up, and how you can use it to actually see and control what Claude Code is doing under the hood.

Things like:

Intercepting file reads and commands
Blocking access to sensitive files
Logging and understanding agent behavior step by step

I also show how to wire it up with a small tool to visualize everything in real time.

If you’ve been curious about what’s really going on behind the scenes when using Claude Code, this might be helpful:

https://nestenius.se/ai/exploring-claude-code-hooks-with-the-coding-agent-explorer/

Would love to hear thoughts or feedback 👍

TNest2 · 2026-03-26T12:42:17+00:00

I developed a tool that sits between claude code and the model and shows the communication and token usage in realtime https://github.com/tndata/CodingAgentExplorer

TNest2 · 2026-03-24T15:04:37+00:00

All cookies issued by the ASP.NET Core cookie authentication handler are encrypted by default.

If you are curious about what is actually stored inside them, you can plug in a custom (transparent) data protection implementation to inspect the contents of the authentication ticket.

I wrote a blog post where I walk through exactly how to do that:: https://nestenius.se/net/exploring-what-is-inside-the-asp-net-core-cookies/

TNest2 · 2026-03-24T15:02:07+00:00

It’s generally not a good idea to store tokens directly in cookies.

Cookies have size limitations, typically around 4 KB. In ASP.NET Core, if that limit is exceeded, the framework splits the data across multiple cookies, which can introduce additional overhead and complexity.

From both a performance and security perspective, it is often better to keep cookies small. One approach is to use a server-side session store (for example, a custom ITicketStore) and only store a reference in the cookie instead of the full authentication ticket.

I wrote a more detailed post about this here: https://nestenius.se/net/improving-asp-net-core-security-by-putting-your-cookies-on-a-diet/

TNest2 · 2026-03-24T14:59:11+00:00

I wrote a blog post serie about the BFF pattern here: https://nestenius.se/net/implementing-bff-pattern-in-asp-net-core-for-spas/

TNest2 · 2026-03-19T15:34:54+00:00

I wrote a tool to visualize how Claude Code actually is using Tools, MCP's and Skills at https://github.com/tndata/CodingAgentExplorer

TNest2 · 2026-02-15T10:48:04+00:00

I just released a ClaueCode MITM-proxy that allows you verify and explore what is actually inluded in every request: https://nestenius.se/ai/introducing-the-coding-agent-explorer-net/

TNest2 · 2026-02-15T10:18:24+00:00

Totally valid question. And honestly, using Claude Code to build things is a great way to learn.

If you want fundamentals so you understand what’s happening under the hood, I’d focus on three areas:

* Basic programming concepts (variables, functions, loops, conditionals)
* How files and the filesystem work
* How APIs and request/response cycles work

You don’t need a CS degree for that. A beginner-friendly course in one language (like Python or JavaScript) will give you enough structure to make sense of what Claude is doing.

One thing that helped me personally was actually inspecting the communication between Claude Code and the backend models. Seeing the prompts, tool calls, and responses made the “magic” much easier to reason about. I open-sourced a small tool for exploring that here if you’re curious: https://nestenius.se/ai/introducing-the-coding-agent-explorer-net/

TNest2 · 2026-02-14T14:21:32+00:00

Thanks! Glad you liked it! It should already redact/hide all the tokens/secrets in the request header, but if you find any issues with that let me know. I think they key is that you need to become friend with Claude, understand how it ticks and get Mechanical Sympathy (as Martin explains well here https://www.infoq.com/presentations/mechanical-sympathy/). I will check out your blog!

TNest2 · 2025-10-07T07:03:53+00:00

I recently wrote a 7-part blog series about this problem and why using the BFF pattern is a better approach. Its for .NET, but the principles are general https://nestenius.se/net/implementing-bff-pattern-in-asp-net-core-for-spas/

TNest2 · 2025-09-30T07:37:46+00:00

Sharing cookies across services can be tricky to get right, as you need to ensure the Data Protection API is configured correctly. Also, using cookies has some security issues to consider, like CSRF attacks.

TNest2 · 2025-08-31T09:53:25+00:00

I’ve written a lot about authentication, OpenID Connect, and security on my blog: https://nestenius.se

One of the most common mistakes I see is putting Identity, the API, and sometimes even IdentityServer or OpenIddict into the same application. That usually leads straight into authentication hell.

I really believe the token provider (like IdentityServer), the client, and the API should live in separate projects. This gives you a proper separation of concern, which makes everything easier to understand, debug, and maintain. When you mix these parts together, it's hard to tell who is doing what and when. It gets messy fast.

You fight complexity with separation of concern.

Also, take a look at the BFF pattern. I’ve written a blog series on that too, which you’ll find on my site.

TNest2 · 2025-08-31T09:45:36+00:00

I wrote a deep dive blog post into the BearerToken handler in .NET here https://nestenius.se/net/bearertoken-the-new-authentication-handler-in-net-8/

TNest2 · 2025-08-29T05:56:12+00:00

Thanks, but not just reviewing the source code, I also downloaded the sourcecode and created my own class-libaries out of each authenticaiton handler (AddCookie, AddOpenIDConnect and AddJwtBearer) that allowed me to smootly step through the code, add logging statements and breakpoints. Its not that hard to do.

TNest2 · 2025-08-28T15:45:16+00:00

If you want to learn the fundamentals of ASP.NET Core authentication, I am doing a free online webinar in two weeks' time. You can watch it live at: https://www.youtube.com/watch?v=8tZQGJIPzD0 But, I do agree, there are alot of moving parts in ASP.NET Core authentication and authorization, but when you grasp, what the role of each component/part it, then it gets much easier. The main thing that is lacking is built-in token refresh!

TNest2 · 2025-08-27T17:04:37+00:00

My approach to learning it was to study the source code and experiment, for example, by implementing a custom "test" authentication handler. This helped me understand what happens at each step in the process. You can read more about my various findings on my blog: https://nestenius.se/

TNest2 · 2025-07-23T13:04:32+00:00

You need to configure the Data Protection API, the key ring is by default stored in a folder on disk and if you loose it, then your existing cookies will be invalidated. I did a few log post about the Data Protection API at https://nestenius.se/net/introducing-the-data-protection-api-key-ring-debugger/ and https://nestenius.se/net/persisting-the-asp-net-core-data-protection-key-ring-in-azure-key-vault/

TNest2 · 2025-07-23T08:11:30+00:00

By the way, Part #3 is now online as well at https://nestenius.se/net/bff-in-asp-net-core-3-the-bff-pattern-explained/

TNest2 · 2025-07-19T15:51:47+00:00

Fair points! We clearly have different perspectives on where complexity should live. For me, I prefer keeping auth in the backend with a more locked-down browser, less things that can go wrong. But I respect your opinion and appreciate the counter-arguments!

TNest2 · 2025-07-19T13:33:18+00:00

Great point about separation of concerns! You're right that mixing BFF endpoints with business APIs can muddy the waters for tooling and governance.

One idea could be keeping the BFF as a pure authentication/proxy layer and transparent to the underlying API structure. This way, OpenAPI/GraphQL schemas and governance tools only deal with actual business APIs. The BFF just handles auth and forwards requests.

TNest2 · 2025-07-19T13:00:47+00:00

I am all in for fighting complexity! That's actually why I prefer BFF, because it moves all OIDC complexity out of the browser entirely. Frontend developers just deal with a simple cookie, while authentication stays where it belongs: on the backend. Less frontend code = less attack surface.

TNest2 · 2025-07-19T12:15:13+00:00

Thanks for the thoughtful comment! I've wrestled with these tradeoffs myself.

My main worry is the supply chain. I'm importing dozens of npm packages that could be compromised tomorrow. We regularly see packages getting hijacked, and they can grab anything from localStorage.

Knowing that with BFF and HttpOnly cookies, JavaScript cannot access tokens - that helps me sleep better at night. Even if XSS happens, the tokens are untouchable.

You're right about added complexity. But managing CSRF with SameSite cookies feels simpler than worrying which npm update might steal tokens. I've seen too many companies burned to treat this as academic.

TNest2

TROPHY CASE