Possible Claude account suspension during OpenHarness testing

[siaochuan]

Hi all,

I want to share a warning in case anyone else runs into something similar.

I was recently suspended by Claude, and I suspect it may have happened while I was testing OpenHarness-related workflows. I do not have confirmation from Anthropic, so this is only my personal guess, but one possible explanation is that some of my testing activity may have been misinterpreted as traffic distribution, account sharing, or another unauthorized usage pattern.

I am opening this issue mainly to remind others to be careful when testing Claude-related integrations through third-party/open-source tooling, especially if the usage pattern could look unusual from the provider side.

If anyone has seen something similar, has suggestions on safer testing practices, or has experience appealing this kind of suspension, I would really appreciate your advice.

You can reach me here on GitHub or by email: tdrowsed@gmail.com

Thanks.

[tjb-tech]

Thanks for sharing this, and sorry to hear about the suspension.\n\nAt the moment, we do not have enough evidence to conclude that OpenHarness itself caused the suspension, so we should be careful not to overstate the connection. But this is still a useful warning for anyone testing third-party or non-standard workflows against provider accounts.\n\nMore generally, users should make sure their usage stays within the provider’s Terms of Service and avoid any patterns that could be interpreted as account sharing, traffic forwarding, or unsupported automated access.\n\nAs a practical alternative, if your goal is to reliably use tools like OpenHarness / ohmo for day-to-day agent workflows, you may also want to try the OpenAI / Codex subscription route. In our experience, that path has been relatively more open to this style of usage. For example, we personally use OpenAI subscription with ohmo / oh in regular workflows.\n\nIf you receive any clarification from Anthropic (for example, whether they confirmed a specific policy reason), feel free to update this thread — that would be very helpful for others.

[siaochuan]

Thanks, that’s fair.

One extra detail: while debugging, I was switching between Claude, Codex, MiniMax, and DeepSeek setups, and the env/config patterns were pretty similar. That means the shell could sometimes pick up the wrong key from .bashrc or local env config, so requests might go out with the wrong credentials or even to the wrong backend.

This had actually happened before in testing, but it never seemed to trigger anything serious. This time there was an abnormal access/error shortly before the suspension, so that’s why I suspect it may be related.

Still just a hypothesis on my side, but I think it’s a real risk when testing multiple provider integrations, and in my case it may have been config/env confusion rather than anything intentional.

[tjb-tech]

This is a very helpful clarification, thanks.\n\nThe config/env confusion angle makes a lot of sense — especially when multiple provider integrations are being tested side by side and the shell can accidentally pick up the wrong key or backend settings. In that case, the risk is less about intentional misuse and more about credentials or routing getting mixed across providers.\n\nThat is also one of the reasons we have been tightening provider-specific auth resolution and trying to make profile selection clearer, so the active backend and active credentials line up more explicitly.\n\nAs a practical precaution, it is safest to test with an explicitly selected profile and avoid relying on broad global environment variables when switching between multiple providers in the same shell/session.

[siaochuan]

One concrete mitigation that might help here: use OpenHarness-specific env vars / auth fields instead of directly consuming the providers' standard global env vars.

Right now many providers look very similar at the API layer, and the key names / config patterns are similar enough that a shell session can easily pick up the wrong credential from .bashrc, direnv, or other shared environment setup. In my case, that is exactly the class of mistake I suspect happened.

So it may be worth introducing a separate auth namespace at the project level, with field names that are intentionally distinct from the providers' native env names. For example, instead of relying directly on ANTHROPIC_API_KEY, OPENAI_API_KEY, MINIMAX_API_KEY, DEEPSEEK_API_KEY, etc., OpenHarness could support namespaced values such as OH_ANTHROPIC_API_KEY, OH_OPENAI_API_KEY, OH_MINIMAX_API_KEY, OH_DEEPSEEK_API_KEY (or profile-scoped auth blocks), and then translate them internally into the provider-specific request format.

That would help in two ways:

1. It isolates OpenHarness auth resolution from whatever global provider env vars happen to exist in the current shell.
2. It makes it much harder to accidentally send the wrong key to the wrong backend during repeated debugging across multiple providers.

A reasonable precedence order might be:

1. explicitly selected profile
2. OpenHarness-namespaced env vars
3. provider-native env vars only as an optional fallback

That seems safer than reading the provider-native env vars directly as the primary source, especially now that many providers expose very similar OpenAI-compatible or near-compatible interfaces.