# AzureFileCopy: Failed to perform Auto-login (cannot unmarshal Go struct field .Token)

## TL;DR
The AzureFileCopy task's auto-login hands AzCopy a token payload in a shape AzCopy does not expect, and AzCopy crashes parsing it. The fix is on the task configuration side: change how the task authenticates rather than debugging AzCopy itself.

## The error
```
Failed to perform Auto-login: json: cannot unmarshal object into Go struct field .Token of type string
```

## Fix it
1. Open the failing AzureFileCopy task in your pipeline and check the service connection it uses. Expected: you know which connection and auth scheme is in play.
2. Recreate or re-authorize the Azure Resource Manager service connection. Stale connection metadata is the usual trigger. Expected: the connection validates cleanly.
3. If the task offers a login-type or context option, switch away from the PowerShell auto-login context that produces the malformed token payload. Expected: the task logs in through the working path.
4. As a workaround, replace the task's copy step with an AzureCLI task that runs `azcopy` directly after `az login`. Expected: the copy succeeds outside the broken auto-login path.
5. Rerun the pipeline. Expected: no more unmarshal error.

## When to use this
- An agent sees the "cannot unmarshal object into Go struct field .Token" error from AzureFileCopy v6.
- Azure DevOps pipelines using the PowerShell login context.

## When NOT to use this
- AzCopy permission errors (AuthorizationPermissionMismatch). Those fail later, at the storage call.
- Generic AzCopy non-zero exits without the unmarshal message.

## Compatibility
- AzureFileCopy task v6, Azure DevOps Services, AzCopy v10.

### Variant phrasings
- "Failed to perform Auto-login"
- "cannot unmarshal object into Go struct field"

## Root cause
The task builds a token object for AzCopy's auto-login, but the shape does not match the Go struct AzCopy expects: an object arrives where a string was declared. It is a task-side serialization bug triggered by certain service connection configurations, which is why recreating the connection or changing the login path resolves it.

## Edge cases
- The error is intermittent across agents when the service connection was created long ago. Recreating it is still the fix.
- Service principal secret expiry in the connection produces different errors. This one is specifically the JSON shape mismatch.