Saved Sign-ins

Let SphereHarness fill a password from Windows Credential Manager into a desktop program's log-in dialog or a web page in Chrome or Edge — while the AI never sees, reads, types or stores the password. You register which password may go where; SphereHarness checks the box and the window, writes the password, and tells the AI one word: “filled”.

What the AI may and may not do

• May: list the labels of your saved sign-ins, click into the password box, ask SphereHarness to fill it, and click Sign in afterwards.
• Never, and refuses: ask you for a password, type or paste one, put one on the clipboard, read one back, click a “show password” toggle, solve a captcha, enter a one-time code (MFA / OTP / “approve on your phone”), answer security questions, create accounts or change passwords. If no saved sign-in matches, it stops and asks you to sign in yourself.

1. Add the password to Windows Credential Manager

SphereHarness can use only generic credentials.

With Control Panel: Control Panel → User Accounts → Credential Manager → Windows Credentials → Add a generic credential (not “Add a Windows credential”). Internet or network address = the target name, e.g. SphereHarness/Vault; User name = the user name the program or site expects; Password = the password → OK.

With cmdkey (Command Prompt or PowerShell):

cmdkey /generic:SphereHarness/Vault /user:jdoe /pass

End the line with /pass and nothing after it, press Enter, and type the password at the prompt Enter the password for 'jdoe' to connect to 'SphereHarness/Vault':. cmdkey shows nothing while you type (no letters, no stars) and answers Credential added successfully.

• Never write /pass:yourpassword — a password on the command line ends up in the shell history, process lists, logs and any transcript or recording.
• Never pipe the password into cmdkey. It reads the keyboard, not the pipe: piped text is ignored and an empty password is stored without a warning.
• PowerShell has no built-in command that writes a generic credential — use the same cmdkey line there.
• cmdkey /list shows targets and user names, never passwords.

2. Naming the target

Any generic entry works; to keep the list readable call it SphereHarness/<what it signs in to> — SphereHarness/Vault, SphereHarness/teamcenter.example.com. One entry per account, with the user name that program or site expects.

3. Register it — Settings → Saved sign-ins for automation

1. Pick the entry — the page lists your generic Credential Manager entries by target and user name. It never reads or shows a password.
2. Label — the name the AI uses, e.g. Vault (Autodesk).
3. Where it may be filled — a Desktop app (browse to the .exe; only that program at that path; optionally one window by title — Use the window I click fills it in — or class) or a Website: pick the Website match — Exact (one https address, e.g. https://vault.example.com), Wildcard (https://*.example.com) or Regex — and type the address or pattern. The line under it says at once whether it is valid and why not; Test an address shows what it would match; a Wildcard or Regex shows the warning and asks you on a card when you save (see Exact, wildcard or regex). http:// is never filled. Websites: Chrome and Edge only.
4. Also fill the user name — into the box named User name, E-mail, Login or Account of the same sign-in.
5. When to ask — Ask every time (default), Allow for this session, or Always (no card; it warns you and asks you to confirm).
6. May be used unattended — off by default; turning it on asks you to confirm (see Unattended).

Letting a sign-in fill without asking (When to ask: Always, May be used unattended) is confirmed on a card only you can answer. Since 1.3.6 the AI may open and change SphereHarness's own Settings when you ask it to (see Permissions), but it can never answer that card, and it never fills a saved password into SphereHarness's own windows.

4. Exact, wildcard or regex website addresses

A website saved sign-in says where it may be filled in one of three ways (Website match: Exact / Wildcard / Regex). Whichever you choose, SphereHarness compares it with the page's origin only — https:// + host + the port when it is not 443, lower case, international names in their xn-- form — read from the page's own address and cross-checked with the address bar. The path, query, #… part and a user@ in front of the host are never compared: https://evil.example/https://auth.twilio.com and https://auth.twilio.com@evil.example/ are both the site https://evil.example. Only https pages are ever filled, whatever a rule says.

Which one to use

Exact

https://auth.twilio.com fills on any page of https://auth.twilio.com and nowhere else — not https://www.twilio.com, not http://auth.twilio.com, not https://auth.twilio.com:8443. With a port: https://vault.example.com:8443 (port 8443 only; :443 is the same as none). An exact address may be an IP address or localhost (e.g. https://127.0.0.1:8443) because it matches nothing else.

Wildcard

https://*.example.com — the * stands for one or more whole labels in front of example.com.

• Matches: https://login.example.com, https://eu.login.example.com, https://LOGIN.Example.com, https://login.example.com. (trailing dot ignored).
• Does NOT match: https://example.com itself (add an Exact sign-in, or use a regex), https://badexample.com, https://login.example.com.evil.net, https://login.example.com:8443 (another port), http://login.example.com, https://evil.net/login.example.com, https://login.example.com@evil.net.
• With a port: https://*.example.com:8443 matches only port 8443; without a port, only 443.
• International names: https://*.bücher.example is kept as https://*.xn--bcher-kva.example and matches https://shop.bücher.example, not the look-alike https://shop.bucher.example.

Regex

A .NET regular expression compared with the whole origin — always anchored, as if written ^(?:…)$, letters without case. Examples:

• https://(auth|login)\.example\.com — exactly those two hosts.
• https://(auth|login)\.example\.com(:8443)? — the same, on port 443 or 8443.
• https://([a-z0-9-]+\.)+example\.com — every sub-domain (the same as the wildcard).

The rules: it begins with the literal https://; escape the dots (\. — an unescaped dot matches any character); no / after https:// (an origin has no path); no | outside a group; only ( ) and (?: ) groups — no look-arounds, back-references, named groups or inline options; no spaces or #; at most 300 characters. It runs on a linear-time engine with a time limit, so no pattern can hang.

Before a regex is accepted it is tested against generated addresses and refused if it matches a non-https address (http://, ws://, file://, chrome-extension://…), an IP address or localhost (unless ticked) or a site nobody here owns: a host under a bare public suffix (https://zzprobeq.com, https://zzprobeq.github.io), a domain that merely ends with yours (https://zzprobeqexample.com), or yours followed by another domain (https://auth.example.com.zzprobeq.com).

Allow IP addresses and localhost

Wildcard and Regex only, off by default — for a test or intranet server you run yourself. Even ticked, a rule never matches a non-https address or “every site”. The check is by name: a public host name that points at your own PC (such as *.localtest.me) is an ordinary site to it.

Test an address

Paste any address (with a path, query, upper case) into Test an address: the page shows the origin SphereHarness would compare and the result — “Match: https://eu.login.example.com would be filled.” or “No match (https://evil.net): …”. Try the addresses you expect AND a few you do not.

The warning and the confirmation cards

• A Wildcard or Regex rule shows the warning “This password may be filled on every site this pattern matches.”
• Saving a new or changed Wildcard / Regex rule (ticking Allow IP addresses and localhost counts as a change) raises its own person-only card. Deny = that rule is not saved: a new pattern sign-in is not saved at all, a changed one keeps its previous address.
• May be used unattended on a pattern needs a second, separate confirmation after the usual unattended card (“Second confirmation: … SphereHarness will fill it WITHOUT a card on ANY site this pattern matches”). Both must be allowed; Deny on the second saves the sign-in without unattended use. Changing the pattern of an unattended sign-in asks again.
• The fill card names the actual site and the matching rule: “Fill the password for Example into https://eu.login.example.com (chrome)? This site matched the wildcard rule https://*.example.com - check it is the site you expect.”
• Only you answer these cards — not the AI, not unattended mode.

What Recent fills shows

Every fill records the actual site filled and the rule that matched, e.g. 2026-10-05 10:12 · Example · https://eu.login.example.com (chrome) · matched wildcard https://*.example.com · allowed once · route value · filled. Unattended fills write the same into the unattended log. Never the password or user name.

5. What a fill looks like

1. The AI (or the browser agent in Chrome) fills the ordinary fields and clicks into the password box.
2. It asks SphereHarness to fill the saved sign-in by its label.
3. A card appears: Fill the password for Vault (Autodesk) into Connectivity.VaultPro.exe – Log In? — Allow once, Allow for this session (until the desktop agent restarts or you click Revoke session allowances) or Deny. No answer in 5 minutes = nothing is filled. For a wildcard / regex sign-in the card also names the rule that matched the site.
4. SphereHarness checks everything again and writes the password; dots appear.
5. The AI is told filled — never the password, never the user name — and clicks Sign in itself.
6. From then on, while that window is open, the filled box reads as (filled from saved sign-in) in everything the AI can look at — the element list, the window's text, the summaries after a click — and is painted grey in screenshots. A box in a bound program or site that holds a saved user name reads the same way, however it got there.

Whatever the box held before is replaced, never added to: a user name box that already shows another name ends up holding exactly the saved user name. SphereHarness then checks the box holds exactly the saved value (a password box: as many characters as the saved password, where the program lets that be measured); if not, it empties the box again and the AI is told write_failed.

Only the box that has the keyboard cursor, in a window that is in front, is ever filled — the AI cannot point at a different box, and you see the fill happen.

Use an entry you name in chat — any window

You can also name a Windows Credential Manager entry in chat (“sign me in with my entry SPHEREHARNESS-HARIVAMSI”) and SphereHarness fills it into the box with the cursor in any window, with no saved sign-in. The AI says which entry and window first. A card appears every time (unattended mode never answers it): Fill the password of the Windows Credential Manager entry 'SPHEREHARNESS-HARIVAMSI' (user h***@customizecad.com) into chrome.exe - “Sign in” on the page login.example.com? — Allow once, Allow for this session (this entry in this program / site), Allow and save as a saved sign-in for this window, or Deny.

Only you name the entry — never a web page, a document or a tool result. The same checks apply, plus: a password box (a visible text box only for the user name), never SphereHarness's own windows, never a program running as administrator, never the secure desktop, in a browser only an https page whose address bar agrees. Windows / Microsoft / developer-tool entries (WindowsLive:, MicrosoftAccount:, git:…) are refused by name. A Windows (domain) entry gives only its user name.

6. Unattended

While SphereHarness runs unattended, a fill happens without a card only for a saved sign-in you ticked May be used unattended; any other is refused (unattended_not_allowed) and never queued as a card for later.

• Every check below still applies; a failed check is refused, never asked.
• Every unattended fill is listed in Settings → Saved sign-ins → Recent fills (time, label, program or the actual website, the matching rule for a wildcard / regex, turn, outcome — never the password or user name) and in the unattended log.
• A wildcard / regex sign-in can be ticked for unattended use only after a second confirmation (see the cards).
• After the run a tray notice names what was filled, e.g. “SphereHarness filled 2 saved sign-ins while unattended - Vault (Autodesk), Teamcenter. Open the list.”

Vault entries usable unattended

An unattended run may follow a skill, knowledge item or automation that names a Credential Manager entry. It is filled without a card only if you listed it in Settings → Saved sign-ins for automation → Vault entries usable unattended (empty by default), optionally only into programs (e.g. Connectivity.VaultPro.exe) and only on websites (e.g. vault.example.com, *.example.com; websites alone = browser pages of those sites only). Adding or widening an entry asks you on a card. An unlisted entry is refused (unattended_not_allowed, with how to list it); outside its programs / websites: unattended_target_not_allowed. Every such fill is in the unattended log and Recent fills with the entry, the window and who asked, and in the tray notice.

Prefix pattern (1.3.8). An entry may end in a single * to cover every Credential Manager entry whose name starts the same way, e.g. SphereHarness-Lease-* (the per-job credentials a worker PC gets from the coordinator). Nothing else is a wildcard: a * anywhere but the end, or a ?, is rejected, and at least 8 characters must come before the *. Matching ignores upper / lower case. A pattern with fewer than two - separated parts before the * (e.g. SphereHarness-*) is accepted but Settings warns that it is broad. The program / website limits apply to a pattern exactly as to an exact entry. Adding one asks you on a card that says it covers every entry with that start; only you can answer it. Each fill through a pattern is recorded with the concrete entry filled and the pattern that allowed it, in the unattended log and the tray notice.

7. Rate limits

Each saved sign-in: at most 3 fills in 10 minutes and 20 a day (change them per saved sign-in: 1–10 and 1–100); the password and the user name are counted separately, so one sign-in uses one of each.

• Only real fills count — a value written into a box (also one that did not verify and was emptied again, write_failed). A refused attempt (the wrong box, not_username_field, no_focus, origin_mismatch, pattern_invalid, …) or a refused approval does not use up a fill, so a retry after a mistake still works.
• Refused attempts have their own, stricter limit: 20 refused fill requests in 10 minutes, all saved sign-ins together — an AI that keeps probing boxes, labels or sites still stops quickly.
• Attended and unattended fills share the counters. Over either limit: rate_limited.

8. What is checked before every fill

Twice — before the card and again immediately before writing; any change in between refuses.

• The box with the cursor is a password box (for the user name: a box named like one), enabled and visible.
• Its window is in front, on your normal desktop (never the Windows secure desktop), and not running as administrator.
• Desktop app: the program's full path is the registered one (a copied or renamed program does not match), plus the title / class rule if set.
• Website: Chrome or Edge; the page's own address is https and its origin matches the rule (the exact address, or the wildcard / regex — origin only, never the path; IP addresses and localhost only where allowed); the address bar agrees; the box is not in a frame from a different site, even one matching the same wildcard.

9. Where things are kept

The password: only in Windows Credential Manager. The saved sign-ins (labels, programs, websites, rules — no passwords): %LOCALAPPDATA%\CADCoPilot\WindowsUi\saved-sign-ins.json; Recent fills, 90 days: saved-sign-ins-audit.jsonl beside it. Nothing leaves the PC. Only the SphereHarness desktop agent can ask for a fill — a coding agent or other program talking to the Windows UI service directly is refused (mcp_door).

10. Revoke or rotate

• Stop one: Settings → Saved sign-ins for automation → Delete. Stop session allowances: Revoke session allowances.
• Remove the password: cmdkey /delete:SphereHarness/Vault, or Credential Manager → the entry → Remove.
• Change the password: change it in the program or site, then edit the vault entry (Credential Manager → Edit, or the same cmdkey /generic:… /pass line, typing the new password at the prompt). Nothing in SphereHarness changes.

11. Programs and browsers

Desktop programs whose password boxes Windows reports as password boxes (WPF, WinForms, classic log-in dialogs). Web pages in Chrome and Edge only — not Firefox, and not the SphereHarness built-in browser, where you still sign in yourself. With the browser agent (Claude in Chrome): it fills the ordinary fields and clicks the password box, SphereHarness fills the password, it clicks Sign in.

12. Refusals — codes and fixes

Troubleshooting