AgentSkillsCN

1password

当您需要管理密钥、凭据、API 密钥或 Vault 操作时使用。支持 Environments(Beta)功能,可挂载 .env 文件。涵盖 1Password、Secrets、OP、Vault、Migrate、Credentials 等工具。注意:此技能不适用于非机密配置(请使用常规配置文件)。

SKILL.md
--- frontmatter
name: 1password
description: Use when managing secrets, credentials, API keys, or vault operations. Supports Environments (Beta) for .env mounting. Covers 1password, secrets, op, vault, migrate, credentials. NOT for: non-secret config (use regular config files).

1Password Operations

Secret management skill using 1Password CLI (op). Routes to workflows for specific operations.

Prerequisites Check

Run first:

bash
op account list

If "not signed in" or error: See workflows/troubleshoot.md


🌟 PREFERRED: 1Password Environments (Beta)

For .env file management, use 1Password Environments instead of manual CLI migration.

Official Docs → | Full Workflow →

Key Insight: UI Creation, CLI Access

Environments are created in the 1Password desktop app UI - not via CLI. However, once created, CLI tools can still interact with secrets via op run and op inject.

code
┌─────────────────────────────────────────────────────────────┐
│                    ENVIRONMENTS WORKFLOW                     │
├─────────────────────────────────────────────────────────────┤
│                                                              │
│  CREATION (UI Only)           ACCESS (Multiple Options)     │
│  ─────────────────            ─────────────────────────     │
│  1Password Desktop App   ──►  • Mounted .env (named pipe)   │
│  • Developer > Environments   • op run (env vars)           │
│  • NOT automatable            • op inject (config files)    │
│                                                              │
└─────────────────────────────────────────────────────────────┘

Why Environments?

  • Secrets never on disk - Named pipe mount, not plaintext file
  • Real-time sync - Changes in 1Password instantly available
  • Team sharing - Grant access with granular permissions
  • Multi-device - Same environment works across all your machines

Setup Flow (One-Time in Desktop App)

  1. Enable Developer features → Settings > Developer > Enable Developer Experience
  2. Create Environment → Developer > Environments > New Environment
  3. Import your .env → Click Import or manually add variables
  4. Set Mount Destination → Destinations tab > Local .env file > Choose path
  5. Authorize → Confirm when prompted

Environments vs CLI: When to Use Each

ScenarioUse EnvironmentsUse CLI (op run/op inject)
Local development✅ Best choiceWorks but more setup
CI/CD pipelines❌ Can't automate creation✅ Service accounts
Team secrets✅ Built-in sharingManual sync needed
One-time scriptsOverkill✅ Quick and easy
Template configsN/Aop inject with .tpl

Mounted .env vs op inject

Mounted .env (Environments):

bash
# App reads .env.local directly (named pipe, no real file)
npm run dev
# Variables available automatically via dotenv

op inject (CLI):

bash
# Template file with secret references (.env.template)
DATABASE_URL=op://prod/db/url
API_KEY=op://prod/api/key

# Inject at runtime
op inject -i .env.template -o .env && npm run build
# Remember to delete .env after!

op run (CLI):

bash
# Pass secrets as environment variables
op run --env-file .env.template -- npm run build
# No temp file created, secrets in process env only

Working Example: songscript

The songscript project uses Environments with 9 variables mounted to .env.local:

  • Environment contains: CONVEX_DEPLOY_KEY, ANTHROPIC_API_KEY, etc.
  • Destination: .env.local (named pipe, not actual file)
  • Works seamlessly with bun dev, npm run dev, etc.

Centralized MCP Secrets (Recommended for Agents)

Problem: Each MCP with op:// refs triggers separate auth prompts.

Solution: Centralize all secrets in one file, launch with op run.

code
~/.config/mcp-secrets/
├── secrets.env          # All op:// refs (one auth loads all)
└── secrets.env.example  # Template (safe to share)

Wrapper scripts:

bash
cursor-secure   # op run --env-file secrets.env -- cursor
claude-secure   # op run --env-file secrets.env -- claude
with-secrets    # op run --env-file secrets.env -- <any command>

MCP configs use empty env:

json
{ "env": {} }  // Inherits from parent process

See ~/Gits/claude-golem/docs/centralized-mcp-secrets.md for full details.

Example: ralphtools Configuration

The ralphtools config could use Environments for sensitive settings:

  1. Create Environment in 1Password: ralphtools
  2. Add variables: NTFY_TOPIC, ANTHROPIC_API_KEY, LINEAR_API_KEY
  3. Mount to: ~/.config/ralphtools/.env
  4. Usage: Scripts source the mounted file or use op run
bash
# Option 1: Source mounted .env
source ~/.config/ralphtools/.env
ralph 10

# Option 2: Use op run with template
op run --env-file ~/.config/ralphtools/.env.template -- ralph 10

Important Limitations (Beta)

LimitationDetails
UI-only creationCannot create/edit environments via CLI
Platform supportMac and Linux only (no Windows)
Max mounts10 enabled .env files per device
Concurrent readsMay have conflicts with multiple processes
Edits in UI onlyChanges to mounted file are lost - edit in 1Password UI
Beta statusFeature may change

When to Use CLI Instead

Use op run or op inject (workflows/migrate-env.md) when:

  • CI/CD pipelines - Need Service Accounts for automated access
  • Scripted operations - Creating items programmatically
  • Template configs - .yml.tpl or .json.tpl files with secret refs
  • Windows - Environments not available on Windows

Quick Actions

What you want to doWorkflow
Use 1Password Environmentsworkflows/use-environment.md
List secrets in vaultworkflows/list-secrets.md
Add a new secretworkflows/add-secret.md
Migrate .env to 1Passwordworkflows/migrate-env.md
Migrate MCP config secretsworkflows/migrate-mcp.md
Fix auth/biometric issuesworkflows/troubleshoot.md

Available Scripts

Execute directly - they handle errors and edge cases:

ScriptPurposeUsage
scripts/migrate-env.shMigrate .env with project/service nestingbash ~/.claude/commands/1password/scripts/migrate-env.sh .env [--dry-run]
scripts/scan-mcp-secrets.shFind API keys in MCP configsbash ~/.claude/commands/1password/scripts/scan-mcp-secrets.sh

Decision Tree

Setting up secrets for a project?

Need to find a secret?

Adding credentials for a service?

Have a .env file to secure?

MCP configs have hardcoded keys?

Biometric timeout or auth problems?


Service Auto-Detection

When migrating secrets, keys are auto-categorized:

Key prefixService folder
ANTHROPIC_*anthropic/
OPENAI_*openai/
SUPABASE_*supabase/
DATABASE_*, DB_*db/
STRIPE_*stripe/
AWS_*aws/
GITHUB_*github/
Othermisc/

Item path format: {project}/{service}/{key}


Vault Organization

Vault Types

VaultPurposeExample Items
developmentGlobal dev toolscontext7, github CLI tokens
PrivatePersonal secretsSSH keys, personal accounts
{project}Project-specificlinear API key, deploy keys
SharedTeam secretsShared service accounts

Creating Vaults

bash
# Create project vault
op vault create "myproject" --description "MyProject secrets" --icon buildings

# Create tools vault
op vault create "development" --description "Global dev tools" --icon gears

Where to Put Secrets

Global dev toolsdevelopment vault:

  • context7, MCP tools, IDE plugins
  • Used across all projects

Project-specific{project} vault:

  • Linear API keys (per workspace)
  • Deploy keys, CI/CD tokens
  • Database credentials

PersonalPrivate vault:

  • SSH keys, personal tokens
  • Accounts only you use

Tagging Strategy

Use tags for cross-vault searching and organization:

bash
# Add tags when creating
op item create --vault development --category "API Credential" \
  --title "context7" 'API_KEY[password]=xxx' \
  --tags "dev-tools,mcp,documentation"

# Search by tag across all vaults
op item list --tags "mcp"
op item list --tags "dev-tools"

Recommended tags:

TagUse for
dev-toolsDevelopment utilities
mcpMCP server credentials
ci-cdCI/CD pipeline secrets
api-keyThird-party API keys
deployDeployment credentials
{project}Project name for filtering

Reference Format

bash
# Vault/Item/Field
op://development/context7/API_KEY
op://myproject/linear/API_KEY
op://Private/github/token

Safety Rules

  1. Never log secret values - Only show masked versions
  2. Dry-run first - Use --dry-run before actual migration
  3. Don't delete .env files - Migration creates .env.template alongside
  4. Verify vault access - Run op vault list before operations
  5. Backup before bulk changes - Export vault if doing large migrations