1Password SSH Agent Not Working: Fix Agent Refused Operation

When the 1Password SSH agent stops working, the failure usually arrives as one of two messages:

sign_and_send_pubkey: signing failed for ED25519 "..." from agent: agent refused operation
git@github.com: Permission denied (publickey).

error fetching identities: communication with agent failed

They point at genuinely different problems, and telling them apart takes one command:

ssh-add -l

If it lists your keys, your client is talking to 1Password and the problem is with approval or vault access. If it returns an error or lists nothing, your client is not reaching the 1Password agent at all, and the socket configuration is where to look.

Why This Happens

The 1Password SSH agent keeps your private keys inside the encrypted vault and signs authentication challenges on request, so the key never touches disk. Three things must line up for that to work:

1. The agent is turned on in the 1Password desktop app.
2. Your SSH client points at 1Password's socket rather than the system agent.
3. The app is running and unlocked so it can approve each signing request.

Break any one and you get one of the two errors above.

Fix 1: Turn On the Agent

In the 1Password desktop app, open Settings → Developer and select Use the SSH Agent. The same screen holds the authorisation preferences that control how often you are prompted.

This is the step most often missed after reinstalling the app or setting up a new machine.

Fix 2: Point Your SSH Client at the Right Socket

The socket path differs per platform, and using another platform's path is a very common cause of error fetching identities.

macOS — add to ~/.ssh/config:

Host *
  IdentityAgent "~/Library/Group Containers/2BUA8C4S2C.com.1password/t/agent.sock"

or export it instead:

export SSH_AUTH_SOCK=~/Library/Group\ Containers/2BUA8C4S2C.com.1password/t/agent.sock

Linux — add to ~/.ssh/config:

Host *
  IdentityAgent ~/.1password/agent.sock

or:

export SSH_AUTH_SOCK=~/.1password/agent.sock

Windows — no SSH client configuration is required. The agent listens on the system-wide named pipe \\.\pipe\openssh-ssh-agent. For Git, make sure it uses the Windows OpenSSH client:

git config --global core.sshCommand "C:/Windows/System32/OpenSSH/ssh.exe"

After changing SSH_AUTH_SOCK, open a new terminal. The variable is read when the shell starts, so existing sessions keep pointing at the old agent.

Fix 3: Handle the "Agent Refused Operation" Case

If ssh-add -l lists your keys but signing fails, the agent is reachable and declining. Work through these in order:

• Approve the prompt. 1Password asks for authorisation on each signature under the default settings. A dismissed or timed-out prompt produces exactly this error. If no prompt appeared, check that the app is running and not minimised to a state where the dialog is suppressed.
• Unlock the app. A locked 1Password cannot authorise a signature.
• Check vault access. If the key lives in a vault the currently signed-in account cannot reach — a common surprise with multiple accounts — the agent will not offer it.
• Check agent.toml if you use one. An agent configuration file that lists specific vaults or items restricts which keys the agent will serve. A key omitted from that list is invisible to SSH even though it exists in 1Password.

Fix 4: Git Uses a Different SSH Than Your Shell

ssh -T git@github.com succeeding while git push fails almost always means two different SSH binaries are in play. This is most acute on Windows, where Git for Windows bundles its own ssh.exe that does not use the Windows named pipe — hence the core.sshCommand setting above. On macOS and Linux, check which binary Git is invoking:

git config --get core.sshCommand
GIT_SSH_COMMAND="ssh -v" git ls-remote git@github.com:owner/repo.git

The verbose output names the agent socket actually used.

Fix 5: WSL

WSL cannot reach the Windows named pipe directly. The usual approach is a relay that forwards the WSL Unix socket to the Windows agent pipe, using a helper such as npiperelay with socat. Configure it once in your shell profile, then treat the WSL side as an ordinary Linux client.

Verify the Fix

ssh-add -l
ssh -T git@github.com

ssh-add -l should list the keys held in 1Password, and the GitHub test should return its success greeting. For a verbose trace showing which agent answered and which key was offered:

ssh -vT git@github.com 2>&1 | grep -i "agent\|offering\|Authenticat"

Prevent It From Recurring

• Keep the private key in 1Password. Exporting it to ~/.ssh "to make things simpler" puts an unprotected key on disk and removes the per-use approval that makes the agent worth using.
• Set IdentityAgent in ~/.ssh/config rather than relying on SSH_AUTH_SOCK, so the setting survives new shells, cron jobs, and editors.
• Use Host * deliberately. It routes every host to 1Password; scope it to specific hosts if you also use keys from another agent.
• Document the platform-specific path in your team setup notes — mixing the macOS and Linux socket paths is the single most common cause of this error.
• Turn on biometric unlock so approving a signature is quick, and you are not tempted to weaken the authorisation settings.