op item move and op item edit fail on items with UNKNOWN field type (Sign in with Google/Apple) — breaks AI-native CLI workflows

[blueCycle]

Summary

op item move and op item edit fail with an identity inconsistencies error when an item contains a field of type UNKNOWN. This type is assigned by the 1Password browser extension when it saves a "Sign in with Google" or "Sign in with Apple" social auth flow. The CLI cannot process these items at all — not to move them between vaults, not to add tags, not to edit any field.

Environment

• op version: 2.34.0
• Platform: macOS 14 (Darwin 24.6.0)
• 1Password plan: Individual

Steps to Reproduce

1. Log into any site using "Sign in with Google" while the browser extension is active — it saves the login with a sign in with field of type UNKNOWN
2. Run either:

```bash
op item move --destination-vault "MyVault"

or

op item edit --tags "my-tag"
```

Result:
```
[ERROR] unable to process line 1: failed to edit due to identity inconsistencies:
for UUID found in the template was inconsistent with found in item to be edited
```

Expected: Item moves/edits successfully, UNKNOWN field preserved as-is.

Root Cause

Inspecting the item via op item get <id> --format=json reveals:

```json
{
"label": "sign in with",
"type": "UNKNOWN"
}
```

The CLI's field type validator does not recognize UNKNOWN and hard-fails the entire operation instead of skipping or preserving the unrecognized field.

Why the Workaround Is Not Acceptable

The only workaround — dragging items manually in the desktop app — breaks AI-native workflows entirely.

I'm using the 1Password CLI with Claude Code (Anthropic's AI coding CLI) to automate credential organization across 690+ items: separating work, personal, and project vaults, applying tags by category, and building clean credential boundaries for a new LLC entity. This is exactly the kind of high-leverage, high-volume task where CLI automation delivers real value — work that would take hours manually, compressing into minutes, enabling a level of organization that simply doesn't get done item-by-item.

When the CLI fails on items with UNKNOWN fields and the fallback is "open the app and drag them," the workflow is broken — not degraded, broken. The value of CLI automation is that it runs end-to-end without human intervention. A step that requires switching to a GUI app, locating the item visually, and dragging it manually doesn't just add friction — it reintroduces the exact human bottleneck the automation was built to eliminate.

For individual users this is a minor annoyance. For anyone building agent-driven or AI-assisted workflows on top of op — which is increasingly common as tools like Claude Code, Cursor, and others integrate with password managers for secrets management — this is a reliability blocker. The UNKNOWN field type will become more common as social auth adoption grows, not less.

Proposed Fix

Option	Behavior	Verdict
Preserve unknown fields	Skip validation on UNKNOWN type; pass through unchanged	✅ Correct fix — no data loss
Ignore unknown fields	Strip on edit/move, log a warning	⚠️ Loses data

Option 1 is correct. The field has meaning — it records how the user originally authenticated. The CLI should not require a field to be a recognized type in order to process the rest of the item.

Affected Items (example)

Items saved with "Sign in with Google/Apple" via the browser extension. In my case: Claude, OpenAI, Eraser, Wispr Flow, Udio, stackblitz, artificialanalysis, Todoist, Zapier, Medium, Exponent — all blocked from vault moves and tag edits.