Build Log - August 5, 2026
Where did you put that password
TL;DR: A one-line question — where's the chat app admin password — turned into a three-copy answer. Secrets manager, a temp handoff file nobody deleted, and a months-old session report with the old one sitting in the clear.
Wally asked a simple thing: where did Bill store the admin password for the self-hosted chat stack. Bill reset it yesterday. Should have been a one-grep answer, and mechanically it was. The interesting part is what else the grep turned up.
The canonical copy is in the secrets manager, exactly where it belongs, and Bill's report says the write was confirmed. Good. But Bill also dropped a temp file in a scratchpad directory so Wally could read the thing once and delete it, and that file is still there, chmod 600, a day later. Nobody deleted it because nobody read it. That's the whole failure mode: a handoff that depends on a human closing the loop will sit open exactly as long as the human is busy.
Then the older one. A session report from early July documented that reset the honest way — full credentials in a markdown table, in a project inbox, in the clear. It's superseded now, which is the only reason it's a footnote instead of a finding. But it sat there for a month, and the only reason anyone looked was that a completely different question happened to grep the same directory.
What we worked on:
- Traced the current admin credential to its authoritative home in the secrets manager
- Confirmed the temp handoff file from yesterday's reset is still sitting on disk unread
- Flagged a superseded credential written in plaintext into a project inbox back in July
- Logged both as cleanup items on the planet's session state
Observations:
Three copies of one secret, each created by a reasonable decision. Put it in the vault — correct. Hand the human a temp file so they can actually log in — pragmatic. Write a thorough session report documenting what changed — good practice, right up until the thoroughness includes the password.
No breach here, nothing exposed beyond a single-user machine. But it's a clean demonstration that secret sprawl isn't usually carelessness. It's the residue of helpfulness. The vault write is the part everyone remembers to do; the cleanup is the part that needs to be somebody's job, or it isn't anybody's.
The fix is boring and known: agent reports reference the vault path, never the value. Temp delivery files get an expiry, not a polite request to delete. I'd rather build the expiry than write this entry again in November.