`permissions` field of resolved member from user option in slashcommand is missing some permissions if used as user-installable app

[Qjuh]

Description

When you use a slash command with a user option of a user-installed app and select a member having elevated permissions the resolved member in the interaction payload shows a wrong value in its permissions field.

From testing it seems that all permissions that would require MFA on the account (if needed by the guild) are not present on the string containing the permissions bitfield.

This does only happen if the app is not installed as bot on the guild. The permissions are also shown correctly if using a user context menu command on the respective user, but not in a user option of a slash command.

Steps to Reproduce

Use a slash command with a user option of a user-installed app and select a member having elevated permissions.
Notice that in the resolved member in the interaction payload it shows a value in its permissions field that is missing elevated permissions like Manage X or Administrator.

Expected Behavior

The permissions field matching the actual permissions of the member in the channel the command was used in or at least those on the guild level.

Current Behavior

Elevated permissions are missing from the bitfield.

Screenshots/Videos

No response

Client and System Information

Discord 308.1 (90154) - stable
iOS 26.1
Also confirmed to be the same on desktop (since this is not a client issue but about API payloads being wrong)

[vakiliner]

I would like to ask an additional question: has the selected user enabled multi-factor authentication?
I was able to reproduce the error only with the account that didn't have multi-factor authentication enabled
My main account does have multi-factor authentication enabled, so when I selected it, the bitfield in permissions returned the correct value

[infinitestory]

I would like to ask an additional question: has the selected user enabled multi-factor authentication? I was able to reproduce the error only with the account that didn't have multi-factor authentication enabled My main account does have multi-factor authentication enabled, so when I selected it, the bitfield in permissions returned the correct value

fwiw, I don't think this is a bug with the interaction data resolution. If a guild requires MFA for moderation actions (this is in the guild safety settings), then users without MFA de facto do not have elevated permissions.

[vakiliner]

I would like to ask an additional question: has the selected user enabled multi-factor authentication? I was able to reproduce the error only with the account that didn't have multi-factor authentication enabled My main account does have multi-factor authentication enabled, so when I selected it, the bitfield in permissions returned the correct value

So, I screwed up twice in the previous test.
First, I didn't grant administrator rights to my role; I simply assigned the old role to my second account without checking the permissions.
Second, my second account had multifactor authentication enabled, and I thought it was only enabled on the primary account.
But after rerunning the test, the results didn't change.
It turns out like a math problem: Incorrect solution, but correct answer.

[Qjuh]

The users do have MFA enabled and it happens both in guilds that do or don't have MFA requirement enabled. We confirmed this behavior with several different users, several different user-installed apps and several different accounts.

[vakiliner]

I couldn't reproduce the issue with guilds that don't require MFA.
You mentioned that this issue only occurs with the user app installation, but I was able to reproduce it without the user app installation.

[Qjuh]

It looks like this is more complicated than I thought initially. I just tested on the official Discord Developers guild and the permissions requiring MFA show for half of the moderators there, while they are missing for the other half. So it's neither about the guild requiring MFA nor just about it being a user-installed app.