fix(skills/1password): stop forcing tmux for desktop app auth (#52540) (#81825)

* fix(skills/1password): stop forcing tmux for desktop app auth (#52540)

The bundled skill currently mandates that every `op` invocation run inside
a fresh tmux session. That guidance is wrong on every desktop-app-integration
setup (macOS/Windows/Linux) because the 1Password app exposes the CLI over
a per-user Unix domain socket the gateway exec env can reach but tmux
subshells generally cannot — wrapping in tmux produces "1Password CLI
couldn't connect to the 1Password desktop app" failures.

Rewrite the skill to detect auth mode first and only use tmux for the one
case where it actually helps:

- Service account (`OP_SERVICE_ACCOUNT_TOKEN`): direct exec, no signin.
- Desktop app integration: direct exec, never tmux. Note the macOS socket
  location (`~/Library/Group Containers/2BUA8C4S2C.com.1password/t/`) so
  agents can recognize the failure mode.
- Standalone interactive signin: tmux is the right tool because it
  preserves the per-shell session token written by `op signin`.

Update Guardrails and the get-started reference accordingly. Drop the
blanket 'do not run op outside tmux' rule.

Fixes #52540

* fix(skills/1password): correct desktop-app IPC wording and signin example

Address PR #75090 review:

- Replace the blanket 'per-user Unix domain socket' description with
  per-platform wording: XPC via the 1Password Browser Helper on macOS,
  a Unix domain socket on Linux, a named pipe on Windows. Keep the macOS
  group-container path as a symptom indicator only, not as a transport
  claim. Mirror the same correction in the get-started reference and the
  changelog entry.
- Fix the standalone-signin tmux example: `op signin` was being sent as
  a plain command, so its eval-style export was printed but never applied.
  Subsequent `op whoami` and `op vault list` calls would fail because
  the OP_SESSION_* env var was never set. Wrap the call in
  `eval "$(op signin ...)"` so the session token is exported into the
  tmux pane environment as the surrounding text describes.

Same direct-exec direction; tighter and more accurate.

* docs(1password): clarify Windows standalone signin

* Potential fix for pull request finding

Co-authored-by: Copilot Autofix powered by AI <175728472+Copilot@users.noreply.github.com>

* fix(skills/1password): repair auth-mode guidance

---------

Co-authored-by: Copilot Autofix powered by AI <175728472+Copilot@users.noreply.github.com>
Co-authored-by: openclaw-clownfish[bot] <280122609+openclaw-clownfish[bot]@users.noreply.github.com>

skills/1password/SKILL.md

@@ -35,36 +35,80 @@ Follow the official CLI get-started steps. Don't guess install commands.
 
 1. Check OS + shell.
 2. Verify CLI present: `op --version`.
-3. Confirm desktop app integration is enabled (per get-started) and the app is unlocked.
-4. REQUIRED: create a fresh tmux session for all `op` commands (no direct `op` calls outside tmux).
-5. Sign in / authorize inside tmux: `op signin` (expect app prompt).
-6. Verify access inside tmux: `op whoami` (must succeed before any secret read).
-7. If multiple accounts: use `--account` or `OP_ACCOUNT`.
+3. Detect the auth mode the user has set up:
+   - **Service account:** `OP_SERVICE_ACCOUNT_TOKEN` is set (typical for headless setups, CI, gateways).
+   - **Desktop app integration:** the 1Password desktop app is running with CLI integration enabled (typical on macOS / Windows / Linux desktops).
+   - **Standalone signin:** neither of the above — `op signin` will prompt for an account password every session.
+4. Run `op` according to the auth mode (see below).
+5. Verify access: `op whoami` should succeed before any secret read.
+6. If multiple accounts: use `--account` or `OP_ACCOUNT`.
 
-## REQUIRED tmux session (tmux)
+## Running `op` per auth mode
 
-The shell tool uses a fresh TTY per command. To avoid re-prompts and failures, always run `op` inside a dedicated tmux session with a fresh socket/session name.
+### Service account (preferred for headless / gateway use)
 
-Example (see `tmux` skill for socket conventions, do not reuse old session names):
+Direct exec. No tmux, no signin step.
+
+```bash
+export OP_SERVICE_ACCOUNT_TOKEN="ops_..."
+op vault list
+op read op://app-prod/db/password
+```
+
+### Desktop app integration
+
+Direct exec. **Do not wrap in tmux** — the desktop app integration uses a per-user IPC channel that is established for the gateway's exec environment but is not always reliably reachable from tmux subshells, which run with a different environment context. The transport differs per platform (XPC via the 1Password Browser Helper on macOS, a Unix domain socket on Linux, a named pipe on Windows); the practical rule for an agent is the same on all three: run `op` directly. On macOS, a useful symptom indicator is the 1Password integration group container at `~/Library/Group Containers/2BUA8C4S2C.com.1password/t/`.
+
+```bash
+op vault list      # may trigger Touch ID / Windows Hello / system auth on first call
+op whoami
+```
+
+If a call returns `1Password CLI couldn't connect to the 1Password desktop app`, do not switch to tmux. Confirm the desktop app is running and unlocked, then retry direct exec.
+
+### Standalone signin (no app, interactive password)
+
+This is the only mode where tmux helps. `op signin` prints an `eval`-style export setting an `OP_SESSION_*` token for POSIX shells; later commands in the same shell are authenticated by that env var. The gateway's per-command shells lose that state between calls, so a persistent tmux pane keeps the session token alive — but only if the export is actually applied with `eval` in a POSIX shell. Sending `op signin` as a plain command leaves stdout printed to the pane and `op whoami` will fail.
+
+The tmux flow is only actionable on macOS/Linux hosts where the `tmux` skill is available. The example intentionally opens `/bin/sh` so the POSIX `eval "$(op signin ...)"` output is valid even when the user's normal shell is fish. On Windows, prefer desktop app integration or service account auth. If the user only has standalone interactive signin on Windows, stop and ask them to provide a persistent PowerShell session mechanism or switch to desktop integration/service account auth; do not translate the tmux commands directly.
 
 ```bash
 SOCKET_DIR="${OPENCLAW_TMUX_SOCKET_DIR:-${TMPDIR:-/tmp}/openclaw-tmux-sockets}"
 mkdir -p "$SOCKET_DIR"
+chmod 700 "$SOCKET_DIR"
 SOCKET="$SOCKET_DIR/openclaw-op.sock"
 SESSION="op-auth-$(date +%Y%m%d-%H%M%S)"
 
-tmux -S "$SOCKET" new -d -s "$SESSION" -n shell
-tmux -S "$SOCKET" send-keys -t "$SESSION":0.0 -- "op signin --account my.1password.com" Enter
-tmux -S "$SOCKET" send-keys -t "$SESSION":0.0 -- "op whoami" Enter
-tmux -S "$SOCKET" send-keys -t "$SESSION":0.0 -- "op vault list" Enter
-tmux -S "$SOCKET" capture-pane -p -J -t "$SESSION":0.0 -S -200
-tmux -S "$SOCKET" kill-session -t "$SESSION"
+tmux -S "$SOCKET" new -d -s "$SESSION" -n shell /bin/sh
+tmux -S "$SOCKET" send-keys -t "$SESSION":0.0 -- 'eval "$(op signin --account my.1password.com)"' Enter
+tmux -S "$SOCKET" capture-pane -t "$SESSION":0.0 -p -S - | tail -40
 ```
 
+Do not queue follow-up commands while signin is prompting. Poll the pane with `capture-pane`
+until signin has either completed and the shell prompt has returned, or it is clearly waiting for
+human input. If the prompt requires a password, MFA, or account choice, pause and ask the user to
+complete signin in their own terminal; give them the socket and session values so they can attach
+locally. The agent should not run `tmux attach` from exec because attach consumes the current TTY and
+prevents scripted `send-keys` / `capture-pane` control.
+
+After the shell prompt returns, verify by sending the checks into the same pane:
+
+```bash
+tmux -S "$SOCKET" send-keys -t "$SESSION":0.0 -- 'op whoami' Enter
+tmux -S "$SOCKET" send-keys -t "$SESSION":0.0 -- 'op vault list' Enter
+tmux -S "$SOCKET" capture-pane -t "$SESSION":0.0 -p -S - | tail -80
+```
+
+Keep the tmux session running so later `op read` / `op run` commands reuse the same authenticated shell.
+
+Use the same `SOCKET` and `SESSION` values for every follow-up command in this standalone signin flow. The `-S "$SOCKET"` flag selects the tmux server socket; keep it in a user-owned `0700` directory, do not share it between users, and choose a new session name for each new signin attempt.
+
 ## Guardrails
 
 - Never paste secrets into logs, chat, or code.
 - Prefer `op run` / `op inject` over writing secrets to disk.
-- If sign-in without app integration is needed, use `op account add`.
-- If a command returns "account is not signed in", re-run `op signin` inside tmux and authorize in the app.
-- Do not run `op` outside tmux; stop and ask if tmux is unavailable.
+- If sign-in without app integration is needed, use `op account add` first.
+- If a command returns "account is not signed in":
+  - service account: re-export `OP_SERVICE_ACCOUNT_TOKEN`
+  - desktop app: confirm the app is running and integration is enabled
+  - standalone: re-run `op signin` inside the same tmux session and authorize

skills/1password/references/get-started.md

@@ -15,3 +15,7 @@
 - After integration, run any command to sign in (example in docs: `op vault list`).
 - If multiple accounts: use `op signin` to pick one, or `--account` / `OP_ACCOUNT`.
 - For non-integration auth, use `op account add`.
+- Desktop app integration uses a per-user IPC channel the CLI must reach. The transport differs per platform (XPC via the 1Password Browser Helper on macOS, a Unix domain socket on Linux, a named pipe on Windows). Run `op` directly from the gateway's exec environment; wrapping in tmux can move the call into a different environment context where the IPC channel is unreachable, producing `1Password CLI couldn't connect to the 1Password desktop app` errors.
+  - macOS: the integration group container lives at `~/Library/Group Containers/2BUA8C4S2C.com.1password/t/` — useful for recognizing the failure mode, not as a reachability test.
+  - Service account auth (`OP_SERVICE_ACCOUNT_TOKEN`) does not use the desktop IPC channel and works the same in or out of tmux.
+- Standalone interactive signin may use tmux only to preserve the `OP_SESSION_*` export in one persistent shell. The tmux example must start a POSIX shell such as `/bin/sh` before sending `eval "$(op signin ...)"`; do not send that POSIX `eval` form into fish or PowerShell.