The demo runs for five minutes. The automation runs overnight.
That difference can turn “authentication works” into a misleading test result.
GitHub CLI now offers opt-in expiring, refreshable OAuth credentials. The announcement explains that gh handles refresh, while consumers that cache a copied access token can eventually hold an expired value. Existing sign-ins do not change unless you opt in.
The subtle bug is assuming that a string copied from a refresh-capable tool is itself refresh-capable.
The tool owns refresh. Your variable does not.
Imagine a fictional job that obtains a GitHub credential when it starts, then uses that same value for every request. The job may keep running after the credential stops being valid.
Restarting the job may appear to fix the problem because startup obtains a fresh value. That is a clue about the lifecycle, not evidence that the intermittent failure disappeared.
For consumers outside the CLI, GitHub recommends obtaining the token fresh through gh auth token when needed. The token belongs in a credential boundary, not in logs, generated reports or a saved task transcript.
Before adding retries, classify the failure
These outcomes need different handling:
| Outcome | What the application should retain |
|---|---|
| The server rejected authentication | An explicit authentication failure |
| The server rejected permission | A permission failure to investigate |
| A read succeeded with no records | A valid empty result |
| The connection ended after a write | An uncertain write outcome |
A catch block that returns an empty array for all four makes the dashboard look calm while hiding the failure.
You can test those branches with controlled responses. No real secret needs to appear in a test fixture.
A retry can turn an auth problem into a duplicate write
Consider a fictional issue-creation request. The server accepts it, but the response is lost. The client cannot tell whether the issue exists.
“Get a new credential and run the whole step again” may create another issue. Authentication recovery and write recovery are separate decisions.
Before replaying an uncertain write, inspect the resulting state or use an idempotency mechanism supported by the destination. Do not invent a universal “safe to retry” rule for every operation.
Test past the demo boundary
A useful rehearsal can force three conditions: authentication rejected, credential reacquired, and a write whose outcome is unknown. Verify both the visible error and the recovery action.
For each consumer, write down who owns refresh, when a credential is acquired, and what survives across runs. Include Git over HTTPS if it uses another credential helper.
This is a lifecycle review, not a claim that every AI agent has this bug. A conventional script can fail in exactly the same way. A long-running agent simply makes it easier to forget how much time has passed since the demo.
I'm Daniil. I write about frontend failure modes and practical engineering decisions. Follow for more worked examples.
What does your automation do when a write succeeds but its response never arrives?
Top comments (0)