> **Can't find what you're looking for?** Use `search_docs` on the docs MCP server at `https://ensforge.com/api/mcp` to find what you need.

# Revoke app access

End an application's ability to use an HCA when a user disconnects it or a session key needs to be
replaced. Revocation is an owner transaction; the session signer cannot revoke its own authority
through this owner-only action.

## Identify the account

Use the same owner and salt as [Update a text record](/hca/rhinestone/update-description).
That guide deploys the account, grants resolver permission, enables a session and verifies a write.
Do not repeat session enablement when revoking access. The owner needs Sepolia ETH for revocation.

## Revoke the sessions

`revokeHcaSessions` revokes **all sessions on this HCA**, including sessions belonging to other apps.
Make that scope clear in your application's confirmation screen before sending the transaction.

Run the following entry point with the original account configuration:

:::code-group
```ts [rhinestone-revoke-access.ts]
// [!include ~/snippets/hca/guides/rhinestone-revoke-access.ts]
```

```ts [account.ts]
// [!include ~/snippets/hca/guides/account.ts]
```

```ts [client.ts]
// [!include ~/snippets/hca/guides/client.ts]
```
:::

## Verify the old permission

The script reads `ENSFORGE_HCA_PERMISSION_ID` and checks it after the revocation receipt. Set that
variable to the permission ID saved when enabling the session, before running the script. It fails
if the old permission is still enabled.

Wait for the revocation receipt before treating access as removed. Revocation prevents future
session execution; it cannot undo calls that already completed. Reconcile any in-flight submission
separately with `getHcaExecutionStatus`.

## Decide what access to retain

Session revocation does not remove resolver permissions granted to the HCA, and the owner can still
execute calls directly. If the account should no longer manage the name, also remove its resolver
permissions using [setRecordPermissions](/sdk/api/permissions/set-record-permissions) with
`approved: false` and the same name and records you originally granted.

To reconnect an app, explicitly enable a new session and store its new authorization. Never reuse
an old permission merely because its original expiry is still in the future.