I haven't tried it, but I think you could keep the full transcript by running a pre-compact hook (on Claude Code) to save your entire conversation history to a file.

As I understand it, Anthropic drew two specific red lines: no mass domestic surveillance, no fully autonomous weapons systems. Seems reasonable to me.

Feels like OpenAI, Google, and Meta have been given a clear path to get federal contracts now by simply not drawing the same lines.

I agree that rejecting valid non-Latin characters in valid contexts is user-hostile, but I should be clearer about scope: this is specifically about machine-readable identifiers (slugs, handles, ENS names) where the character set is intentionally restricted, not display names or user-facing text.

The approach there should be what wongarsu describes below (imo), to style the UI so official accounts are visually distinct (badges, colour, etc.) rather than policing the character set.

namespace-guard is deliberately opinionated for the slug/handle case where you've already decided the output should be ASCII-safe. If your use case is broader than that, confusables detection without rejection is the right call.

Thanks Josh - putting this article out there has pushed me to sharpen a lot of my thinking which hopefully should come across in my more recent work. I've updated the article to scope the NFKC recommendation to identifiers and added a note crediting your correction. Thanks for catching it.

Looks great - well done. Much nicer than stock tmux for sure.

thanks. I am not a frequent tmux user, and always find myself forget about the basic commands after what the hotkey is. So this deadly simple stuff may be useful for those not want to spend too much time but have to use tmux.

Of course Google can restrict how their API is accessed. But locking paid accounts with no warning, no explanation email, and no functioning support path while continuing to charge $249/month is a different problem entirely. A reasonable enforcement process would have been a warning email, grace period to stop using the tool, then restriction.

What an awful way to lose trust, locking out their users but billing them all the same.

Their "API" isn't what's being accessed here. As far as I understand it's using their subscription account oauth token in some third party app that's the issue here.

If they allowed oauth token to work like that then that is their (Google's) problem.

It is basically impossible to disallow the token to work that way on a technical level. It would be akin to trying to trying to set up a card scanner that can deny a valid card depending on who is holding it. The only way to prevent it from working is analyzing usage patterns/details/etc in some form or fashion. Similar to stationing a guard as a second check on people whose cards scan as valid.

Exactly, so charge on usage or cap on usage.

Either the token works for all times, or works until it doesn't, or does not work at all.

Punishing the account for using a token you have vended for the exact same purpose is extremely poor product design.

So it sounds like the trillion dollar corporation can actually do it but they don't want to spend the money too because they are extremely cheap?

Well, it looks like they're not allowing it.

Google have always done this if they suspect you’ve broken TOS, if anything this is better than usual because usually you lose your Gmail and YouTube accounts too with no human to talk to about it.

I was using Antigravity the proper way, but why would I risk my account using this subpar software? OpenClaw and Opencode literally obfuscate the API call exactly like Antigravity calls it. Do you really trust Google to only catch misuse using this dragnet?