Enhancement: no-plaintext credential for an out-of-process stdio MCP client on Windows (DPAPI / Server Manager) — follow-up to #107

Enhancement request. There is no enhancement template; the Bug-reports checklist items are included for completeness.

Context (follow-up to #107)

#107 (closed) surfaced the same setup: an out-of-process MCP client cannot use the
Server Manager credential, and iris_add_server fails with KEYCHAIN_FAILED. Its
resolution (v1.2.0) stopped the crash and made check_config report
keychain_unavailable and fall through to other credential sources. On Windows that
fallthrough is a plaintext password (in .claude.json env, .iris-agentic-dev.toml,
or since 1.4.2 in servers.json). So the underlying need is still open: there is no
supported way for an out-of-process stdio client on Windows to use the credential
Server Manager already holds without a plaintext file — even though check-sm-credential
proves the binary can read it.

Environment

• iris-agentic-dev --version: 1.4.2 (also reproduced on 1.3.0)
• IRIS: IRIS for Windows 2026.3.0AI (Build 136U), Enterprise (Concurrent User license; not Community), not HealthShare
• Deployment: native Windows binary, launched by an out-of-process stdio MCP client (Claude Code) via a PowerShell wrapper. Not the VS Code extension.
• Reproducible: yes, deterministic.

What happens (exact calls + output)

1. iris_add_server on 1.3.0:
   KEYCHAIN_FAILED / keychain_unavailable: true — "OS keychain is unavailable ... no default keychain store. On headless hosts and Remote SSH sessions the keychain daemon is often not accessible to out-of-process MCP clients."
2. iris_add_server on 1.4.2: { "added": true, "stored_plaintext": true, "warning": "Credential stored in plaintext in servers.json — use VS Code Server Manager for production credentials." } — a second plaintext file, not a fix.
   Note: the Windows Credential Manager itself is usable from a normal process in the same interactive session (a cmdkey / CredRead write+read round-trip works). The failure is specific to the binary's keyring backend when it runs out-of-process.
3. check-sm-credential <server> <user> (Windows, DPAPI read of state.vscdb): exit 0, resolves the saved password. The binary can read it.
4. The live mcp server pointed at that same server via --server returns HTTP 401 — the live connection path does not use the DPAPI resolution.
5. check-sm-credential prints no password (masked diagnostic), so a launch wrapper cannot capture it either.

Net: the DPAPI resolver exists but is reachable only as a diagnostic; the live stdio MCP has no no-plaintext path on Windows.

Proposed enhancement (happy to open a PR)

Smallest first:

1. A credential resolve/emit mode — e.g. check-sm-credential --emit, or a resolve-credential subcommand — that prints the resolved password to stdout for a parent process to consume (the git / docker credential-helper pattern). A launch wrapper then sets IRIS_PASSWORD, with nothing on disk and nothing on a command line.
2. Or wire the existing DPAPI resolver into the live mcp connection: when --server/config maps to a Server Manager entry and no explicit password is given, resolve via DPAPI at connect time.

Not this issue

The iris_execute output-capture failures on native Windows are separate and already tracked in #139 (and the non-ASCII variant in #138).

Minor, related

check-sm-credential (and --server lookups) with a username that starts with - need a -- separator, or the argument parser treats it as a flag. Hyphen-leading IRIS usernames are common; accepting them after the options, or noting -- in the help text, would help.

Start with the existing check-sm-credential DPAPI path and the live mcp --server connection path, then trace how iris_add_server selects credential sources. Decide which proposed integration is supported, and verify that an out-of-process Windows stdio client can authenticate without writing or exposing a plaintext password.