sync: auto-sync from HOWARD-HOME at 2026-06-25 11:45:38

Author: Howard Enos
Machine: HOWARD-HOME
Timestamp: 2026-06-25 11:45:38

docs/CT_THOUGHTS.md

@@ -16,6 +16,7 @@
 > The entries below are the current thoughts:
 > 1. ClaudeTools 3.0 — web-based co-work workspace (Mike, 2026-06-14) — **Discussed (vision-stage, no build go)**
 > 2. Web-search bots (grok xsearch + gemini search) reliability - MUST FIX (Mike, 2026-06-17) - **Mitigated/Fixed same day (gemini 3-retry+backoff; grok xsearch auto-falls-back to gemini on timeout). Grok's own multi-agent timeout is upstream/unsolved.**
+> 3. ClaudeTools browser extension — synced website logins + in-browser actions for the ACG team (Howard, 2026-06-25) — **Raw**
 
 ---
 
@@ -280,3 +281,44 @@ the docs before probing" workflow - it has to be dependable.
   budget - that's an xAI-side limitation; the fallback makes xsearch reliable regardless. If grok fixes
   the multi-agent latency (or exposes a lighter single-agent web_search), revisit. Acceptance ("5/5 on
   long queries") now effectively met via the gemini path.
+
+---
+
+## Thought 3 — ClaudeTools Browser Extension (Howard, 2026-06-25)
+
+**Status: Raw — idea parked for discussion. NOT authorized to build.**
+
+### The want
+
+A ClaudeTools browser extension for the ACG team (start with just the browsers Mike and
+Howard actually use — no need to support the whole field). The driving pain: today, when
+someone needs a website password or other site-specific data, they pull it via a Claude
+session. That's heavyweight for a routine "log me into X" task. The extension would let the
+team get that data **directly in the browser** — in sync with ClaudeTools — without
+spinning up Claude every time.
+
+Password store is the obvious first function, but the extension should do **more than a
+password manager**. It's meant to be a ClaudeTools surface living in the browser, keeping
+the team in sync with the same source of truth the harness uses (vault + repo + coord),
+just reachable at the point of work (the website itself).
+
+### Early notes / open questions (to flesh out later)
+
+- **Scope of browsers:** only Mike's + Howard's daily browsers to start. Confirm which
+  (Edge? Chrome? both?) before any build.
+- **What "more than passwords" means** — needs brainstorming. Candidates to explore:
+  per-site credential autofill, surfacing the right vault entry for the current domain,
+  one-click "open client portal" with the right creds, pulling client/site context for the
+  page you're on, quick actions that today require a Claude turn.
+- **Auth + secrets boundary:** the vault is SOPS+age and the canonical secret store. An
+  extension touching credentials is a real security surface — how it decrypts/reads (does it
+  talk to a local ClaudeTools daemon? read-only? per-person identity like the rest of the
+  fleet?) is the central design question. Tie into the same auth thinking as Thought 1
+  (ClaudeTools 3.0) and the `project_ai_auth_product_boundary` model rather than inventing a
+  new path to plaintext secrets.
+- **Sync model:** how the extension stays current with vault/repo changes (poll the coord
+  API? local daemon push? on-demand fetch?).
+- **Relationship to ClaudeTools 3.0 (Thought 1):** possibly a component of, or a precursor
+  to, the web co-work vision — decide whether this is standalone or folds into that.
+
+More ideas to be worked out in discussion before this moves past Raw.