## Summary `glab api` cannot upload binary files as `multipart/form-data`. This makes it impossible to use `glab api` for endpoints that require file uploads, such as [wiki attachments](https://docs.gitlab.com/api/wikis/#upload-an-attachment-to-the-wiki-repository). ## Steps to reproduce ```bash glab api projects/:fullpath/wikis/attachments \ --method POST \ --field "file=@/path/to/file.ods" ``` Returns `HTTP 400 Bad Request`. ## Root cause The `--field`/`-F` flag reads file content via the `@filename` syntax, but sends it as a JSON-encoded string in the request body. The [wiki attachments endpoint](https://docs.gitlab.com/api/wikis/#upload-an-attachment-to-the-wiki-repository) (and others) require `Content-Type: multipart/form-data` with a binary file stream — which `glab api` has no way to produce. Passing `--header "Content-Type: multipart/form-data"` manually does not help, as the body encoding is still JSON. ## Workaround Use `curl` with `--form`: ```bash curl --request POST \ --header "PRIVATE-TOKEN: $(glab auth status --show-token 2>&1 | grep 'Token found' | awk '{print $NF}')" \ --form "file=@/path/to/file.ods" \ "https://gitlab.com/api/v4/projects/:id/wikis/attachments" ``` ## Expected behavior `glab api` should support multipart form-data uploads, either via a dedicated flag (e.g. `--form-file key=@path`) or by detecting binary files passed via `--field` and switching to multipart encoding automatically. ## Environment - `glab` version: 1.89.0 - OS: Ubuntu Linux --- ## By the way The workaround above uses `glab auth status --show-token` to retrieve the token for use in `curl`. This is unnecessarily awkward — it requires grepping and awking through human-readable status output just to get the raw token value. It would be great to have a dedicated command like: ```bash glab auth token ``` ...that returns **only** the token on stdout, with no extra text. This would make it trivially composable: ```bash curl --header "PRIVATE-TOKEN: $(glab auth token)" ... ```