You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
I'm currently trying out oama as a Oauth2 handler for aerc (following this guide) on the current macOS Beta, but I've run into an issue. After successful authorisation, I get the following error:
$ oama authorize microsoft [EMAIL] --device
Visit:
https://microsoft.com/devicelogin
and enter the code:
[CODE]
security: unknown command "token_type":"Bearer"}'"
token_type":"Bearer"}': returned 1
StoreError "Storing secret failed."
I've been able to get it to work briefly by manually appending "token_type":"Bearer"} to the secret in the Keychain Manager, but the whole thing fell apart again as soon as the first token refresh was triggered. So I suspect something has changed (or rather will change as soon as macOS Tahoe comes out) in the way the security tool accepts arguments, which causes it to stop parsing the secret too early, but I'm not exactly sure.
System Info
OS: macOS Tahoe 26.0 Beta 3 (25A5306g)
Shell: zsh
Terminal: kitty
Browser: Vivaldi
Oama version: 0.21.0
Oama distribution: Precompiled darwin-arm64 binary from the GitHub release
Service: Microsoft (my university's Microsoft Exchange)
The client ID I'm using is the one used by Thunderbird which I got from here. I am, however, not using any client secret, as the device code flow doesn't need one if I've understood correctly.
Account Information
The account I'm using is an institutional Microsoft Exchange account from my university.
Your config looks OK, although you don't really need to specify
`auth_scope`.
security: unknown command "token_type":"Bearer"}'"
token_type":"Bearer"}': returned 1
StoreError "Storing secret failed."
```
I've been able to get it to work briefly by manually appending
`"token_type":"Bearer"}` to the secret in the Keychain Manager, but the whole
thing fell apart again as soon as the first token refresh was triggered.
So it almost managed to include the whole json load except the last few bytes.
suspect something has changed (or rather _will_ change as soon as macOS Tahoe
comes out) in the way the `security` tool accepts arguments, which causes it to
stop parsing the secret too early, but I'm not exactly sure.
From your config it looks that it works with your gmail account, right? On my
linux system the json secret is 542 bytes for a gmail account but 2153 bytes for
an outlook account.
It seems to be not so much changing of parsing but hitting the size-limit of the
command line (of the interactive mode) and/or of the `generic-password` storable
in the keyring.
## System Info
OS: macOS Tahoe 26.0 Beta 3 (25A5306g)
Oama version: 0.21.0
Oama distribution: Precompiled darwin-arm64 binary from the GitHub release
The binary was produced on gitgub using macos-15 runner. You can try to compile
it from source on your system and see if that makes any difference.
Your config looks OK, although you don't really need to specify auth_scope.
Okay, perfect.
From your config it looks that it works with your gmail account, right? On my
linux system the json secret is 542 bytes for a gmail account but 2153 bytes
for an outlook account.
I'm not really using that gmail config, to be honest, I just didn't bother
disabling it when I was adjusting the default config file.
It seems to be not so much changing of parsing but hitting the size-limit of
the command line (of the interactive mode) and/or of the generic-password
storable in the keyring.
Yeah, that's very possible. I don't think that it's because of a hard cap on the
size of the storable, however, as I didn't run into a size limit when I manually
appended the rest of the json to it, after which it worked for a while.
The binary was produced on gitgub using macos-15 runner. You can try to
compile it from source on your system and see if that makes any difference.
I have tried that now, but it unfortunately doesn't work with the locally
compiled version either.
I'm not really using that gmail config, to be honest, I just didn't bother
disabling it when I was adjusting the default config file.
Could you try a gmail account account just for testing.
Wondering how that would work because of the much smaller size.
Yeah, that's very possible. I don't think that it's because of a hard cap on the
size of the storable, however, as I didn't run into a size limit when I manually
appended the rest of the json to it, after which it worked for a while.
Right.
I have tried that now, but it unfortunately doesn't work with the locally
compiled version either.
That's what I expected.
I am homing in on a pipe buffering problem ... might push another solution(s) on
a different branch in a few days. Perhaps you could test it.
Could you try a gmail account account just for testing. Wondering how
that would work because of the much smaller size.
Interestingly enough, it did work with a gmail account. I wasn't able to
test it in the exact same circumstances, though, as the google API
doesn't seem to support the device code flow for email authorisation.
I am homing in on a pipe buffering problem ... might push another
solution(s) on a different branch in a few days. Perhaps you could
test it.
I could not reproduce your error using the most recent main branch of oama.
oama version 0.22.0 - 52b76bc clean
A microsoft outlook account just worked fine on Darwin 24.5.
You can download the artifact produced yesterday
oama-0.22.0-Darwin-arm64
run id 16507706161, job id 46682481831.
or just build again from source.
I tried again with the most recent commit on main, but on the beta (darwin 25)
it still throws the error, unfortunately.
Though, just out of curiosity, I also tried it on macOS Sequoia (which is on
darwin 24, I believe) and there it worked, so I think we should be able to rule
out my university's Exchange as the culprit.
Activity
pdobsan commentedon Jul 22, 2025
tifrueh commentedon Jul 22, 2025
Terribly sorry, I've completely missed that section when reading the README.
oama printenvThe output of
oama printenvlooks as follows:The client ID I'm using is the one used by Thunderbird which I got from here. I am, however, not using any client secret, as the device code flow doesn't need one if I've understood correctly.
Account Information
The account I'm using is an institutional Microsoft Exchange account from my university.
Error Messages
The error message I get looks as follows:
Syslog messages that match the term "oama" are the following:
pdobsan commentedon Jul 23, 2025
tifrueh commentedon Jul 23, 2025
Okay, perfect.
I'm not really using that gmail config, to be honest, I just didn't bother
disabling it when I was adjusting the default config file.
Yeah, that's very possible. I don't think that it's because of a hard cap on the
size of the storable, however, as I didn't run into a size limit when I manually
appended the rest of the json to it, after which it worked for a while.
I have tried that now, but it unfortunately doesn't work with the locally
compiled version either.
pdobsan commentedon Jul 23, 2025
tifrueh commentedon Jul 24, 2025
Interestingly enough, it did work with a gmail account. I wasn't able to
test it in the exact same circumstances, though, as the google API
doesn't seem to support the device code flow for email authorisation.
Certainly, I'd be happy to!
pdobsan commentedon Jul 25, 2025
tifrueh commentedon Jul 25, 2025
I tried again with the most recent commit on
main, but on the beta (darwin 25)it still throws the error, unfortunately.
Though, just out of curiosity, I also tried it on macOS Sequoia (which is on
darwin 24, I believe) and there it worked, so I think we should be able to rule
out my university's Exchange as the culprit.
pdobsan commentedon Jul 26, 2025
pdobsan commentedon Jul 26, 2025
tifrueh commentedon Jul 27, 2025
Using eca675f it works like a charm now. Thanks so much for the fix! :)
pdobsan commentedon Aug 29, 2025
solved in release 0.22.0