X connected apps: how to review and revoke access

#Quick answer

Your X connected apps live under Settings and privacy, then Security and account access, then Apps and sessions, then Connected apps. Every app you have ever authorised is listed there with its permissions printed underneath, and a Revoke access button beside it. Click that button and the app loses its access to your account going forward.

Two things about that screen catch people out. Connected apps and login sessions are separate lists, so logging out everywhere does not disconnect an app. And revoking is a stop, not a rewind: it ends future access without touching whatever the app already copied.

Last updated: September 2026

#Where the list lives, and what is on it

On x.com the full path is Settings and privacy > Security and account access > Apps and sessions > Connected apps. X's help page describes the same destination in shorter form, as the "Apps and sessions section of your account settings", and it is the only place the platform documents for this job (X Help, Wayback capture 30 August 2026).

What renders there is a list of every third-party app that holds a live authorisation on your account, each with the specific permissions it was granted printed under its name and description. To disconnect one, X says to "click the Revoke access button next to the app or at the bottom of the page after clicking the app's name."

Do the audit on a desktop browser if you can. The connected-apps list and the session list both render on the same screen there, which matters because the two are easy to confuse and you want to handle both in one pass.

Scroll past the apps and you reach Sessions, a separate list of active logins showing the location and time of each one, with a Log out button per session and a Log out all other sessions button at the top. We covered that half of the screen in how to log out of X. This piece is about the half above it.

#What each permission level actually allows

The permission line under an app name is doing a lot of work, and almost nobody reads it. X publishes what each rung means. For apps using OAuth 1.0a, there are three, and they stack:

Source: X Help, Wayback capture 30 August 2026.

Read that middle row again. An app with read and write can block or report accounts on your behalf, which is not what most people picture when they click Authorize on a scheduling tool. It can also follow and unfollow for you, which is how a badly behaved app turns your account into a follow-churn machine without you noticing until someone asks why you followed them.

Newer apps use OAuth 2.0, which X describes as more granular. Instead of one of three fixed bundles, the consent screen shows two explicit lists: "Things this App can view" and "Things this App can do." That is a real improvement, because you see the specific scopes rather than a category name. It also means the consent screen is worth reading rather than clicking past, since the difference between two apps on the same shelf can be a scope you would have declined.

One more line from the same page deserves quoting: X does not share your password with apps. Separately, apps may ask for permission to view the email address on your account, and X Ads access is its own category covering campaign data and account management.

#Revoking, logging out and changing your password are three different actions

This is the section most guides skip, and it is the reason people think they have cleaned up an account when they have not.

Logging out a session ends one device's login. X adds a caveat worth knowing: while logging a session out prevents further actions such as posting, liking and replying from it, it "may not delete data (e.g., Direct Messages) that was previously cached on the device while the session was active." It is not a remote wipe.

Changing your password ends login sessions. It does not touch authorised apps, which sit in their own list with their own access. We spelled that out in how to change your X password, because it is the single most common wrong assumption after a compromise.

Revoking an app removes that app's authorisation, and nothing else. Your sessions stay live, your password is unchanged.

So a real cleanup is all three, in a sensible order: revoke apps you do not recognise, change the password, then log out all other sessions. X's own instruction for a suspected bad app is the first two of those, and it is unambiguous about the sequence: "Immediately revoke its access on the Apps and sessions section of your account settings and change your password." If you are working through an actual incident, what to do when your X account is hacked walks the full sequence, and turning on two-factor authentication is what stops the next one.

#What revoking does not undo

Here is the part the older guides on this topic never mention, and it changes how you should think about authorising anything.

X states plainly that when you authorise an app, "the app may use, store, and share your information in accordance with its own business practices." Revoking ends the connection. It does not reach into the app's database and delete the posts, follower lists, DMs or email address it already pulled while connected.

That is not the end of it, though. X's Developer Policy puts a real obligation on the other side, under content compliance: if a developer stores X content offline, they must keep it current with X, and "must delete or modify any content you have if it is deleted or modified on X. This must be done as soon as reasonably possible, or within 24 hours after receiving a request to do so by X or the applicable X account owner" (accessed 21 September 2026).

You are the applicable X account owner. That clause is a lever you can actually pull, and it comes with a 24-hour clock attached. If an app held read access to something sensitive, revoking is step one and emailing the developer a deletion request is step two. X is equally clear that it cannot do this part for you: because third-party apps are not owned or operated by X, it does not troubleshoot them, and it points you at the developer.

Worth adding the honest caveat: a policy obligation is a rule the developer agreed to, not a technical guarantee about what sits on their servers. Send the request anyway. It is free, it starts a clock, and it creates a record.

#The iOS integration you cannot revoke piece by piece

One oddity that confuses people mid-audit. Your connected-apps list may show entries like X for iPhone, X for iPad or Camera for iOS, which look like third-party apps and are not.

X documents the behaviour directly: "Though you will see other specific apps like X for iPhone or Camera for iOS listed in your active connections, you cannot revoke access to these individual apps; you have to revoke access for the entire iOS integration" (X Help, Wayback capture 11 August 2025).

In practice: leave those rows alone unless you are deliberately disconnecting X from your Apple devices. Revoking the iOS integration to tidy up a list will sign you out of your own phone, which is a surprising outcome for a housekeeping task.

#How to audit the list without breaking anything

Ten minutes, once or twice a year. X recommends the habit itself, suggesting you "regularly review third-party apps which have access to use your account to confirm that you still want to give them access."

Work down the list and sort each entry into one of four buckets.

• Do not recognise it. Revoke now, then change your password. An unfamiliar name with write access is the highest-priority row on the screen.
• Recognise it, no longer use it. Revoke. A dormant authorisation is still a live key, and the risk is the developer's future security rather than their current intentions.
• Still use it, permissions look too broad. Revoke and reconnect. Permission levels are set at authorisation time, so the only way to downgrade one is to disconnect and authorise again through a screen asking for less.
• Still use it, permissions fit. Leave it. Note what it does so next year's pass is faster.

Two rows deserve a harder look than the rest. Anything holding Direct Messages access, because your DM history is the most sensitive thing on the account and very few tools genuinely need it. And anything granted for a one-off job, like a bulk cleanup tool. A bulk post deleter needs write access to do its work, and the right move is to revoke it the day the run finishes rather than at some vague point later.

#The apps X tells you never to hand a password to

The help page names two categories outright, and says you should "never provide your username and password" to either:

• Websites claiming to help you "get more followers fast!"
• Apps which post affiliate ads to your timeline.

That first category is the more common trap, and we took it apart with the vendors' own numbers in free X followers. The structural point holds regardless of the site: a legitimate integration uses X's OAuth flow, which means you type your credentials on x.com and never into the third party's own form. X's test for this is simple. If you are unsure whether a login page is really using OAuth, go to x.com directly, log in there, then return to the app. If it is using OAuth, it will not ask for your username and password again.

Anything that does ask is not an integration. It is a credential handover, and the access it gains does not appear in your connected-apps list at all, because there is nothing to revoke.

#What this means if you use an automation tool

Any service that posts, follows or messages for you needs write access, and X governs that category under its Automation rules. The Developer Policy is specific about what a service doing write actions must do: follow those automation rules, get explicit consent before sending automated replies or Direct Messages, respect opt-outs immediately, and never perform bulk, aggressive or spammy actions including bulk following.

So there is a practical question to ask of any growth tool: what is it asking for, and where does its access live? A cloud service holds a long-lived token on its own servers, which is a second place your account can be reached from and a second party whose security you are trusting. That token stays valid until you revoke it, whatever happens to the vendor in the meantime.

A different shape is a tool that runs locally and drives X from your own logged-in browser session on your own machine, so there is no server-side token and the session cookie stays where it already is. That is the design behind X-Autopilot, and we compared the two architectures directly in local vs cloud X automation. It is a smaller exposure than a shared cloud service, not an absence of one: browser-driven engagement is a gray area under X's automation rules rather than a sanctioned API path, and no tool of either kind removes account risk. Read the rules before you rely on unattended actions.

#The bottom line

Open Settings and privacy > Security and account access > Apps and sessions, read the permission line under each app rather than the name above it, and revoke anything you do not recognise or no longer use. Then remember what that button does and does not do. It stops the app from acting on your account tomorrow. It does not delete what the app took yesterday, and it does not change your password or end a single login session. For the data already gone, the Developer Policy's 24-hour deletion request is the lever, and you are the only one who can pull it.