Connect to Athenode Pro

Connecting to Athenode Pro means signing the Athenode CLI and your AI coding tools in to the team server with your own Pro account, so that they work in your projects with your project roles. Athenode Pro is the Athenode server a team runs itself, with accounts, project roles and a licence. The CLI signs in through the browser and keeps its sign-in in the system's keychain, never in the repository. Each AI tool signs in on its own the first time it connects, so no token goes into its configuration.

You need an account on the Pro server and the server's public URL, the https address your team opens in the browser, such as https://athenode.example.com. Any account can create a project and becomes its owner. To work in an existing project, an owner or an administrator gives you a role on it, as project roles describes. The athenode daemon, the local Athenode server, does not need to run for a project on Pro.

Sign the Athenode CLI in to a Pro server

You sign the CLI in once per server, the first time you bind a repository to a project on it. You need a terminal and a browser on the same machine, or a browser where you can open an address the CLI prints.

Open a terminal in the root of your repository.

Run init with the server's public URL:

athenode init --server https://athenode.example.com

The CLI prints "Sign in to", the server's address and "in your browser", and opens the browser. If no browser opens, open the address the CLI prints under that line.
Sign in to the server with your password or through single sign-on, and enter your two-factor code if your account has one.
On the consent page, check that the application is "Athenode CLI" and select Allow access.
Return to the terminal, which prints "Signed in.", and answer the questions of init: the project, the plugin, the AI tools, .gitignore and the MCP modules.

The browser tab shows "Signed in to Athenode Pro. You can close this tab and return to the terminal." init lists the projects you have a role on and offers to create one, then installs the plugin as Install a plugin describes. .athenode/config.json records the server, so later runs of init, sync and athenode project in the repository use it without --server. Each project member signs in with their own account, in their own clone.

The CLI waits 5 minutes for the browser. After that it stops with "The sign-in timed out: no answer from the browser." and you run init again. Selecting Deny on the consent page stops it with "The sign-in was refused (access_denied)."

--server keeps the scheme, host and port of the address and drops any path. A value that is not an http or https address stops init with "--server must be a URL such as https://athenode.example.com".

The CLI keeps one sign-in per server, for your user on this machine. It never writes it into the repository or into .athenode/config.json.

System	Where the sign-in is kept
macOS	The login Keychain
Windows	The Windows Credential Manager
Linux	The Secret Service, such as GNOME Keyring or KWallet, through `secret-tool` (package `libsecret-tools` on Debian and Ubuntu), in a desktop session

Where there is no keychain, the CLI keeps the sign-in in ~/.athenode/credentials.json in your home folder, readable only by you. That is the case over SSH, in CI, in containers and on Linux without secret-tool or without a desktop session. The file is also used when the keychain is locked or does not answer within 15 seconds. When the keychain holds the sign-in, the file keeps only a reference to it and no token. Set ATHENODE_CREDENTIALS_STORE=file to keep the sign-in in the file on a machine that has a keychain.

The CLI renews the sign-in by itself when a command needs the server. A sign-in that has not been renewed for 30 days ends, and every sign-in ends 90 days after you signed in. When it has ended, the next command in a terminal opens the browser again. Without a terminal, the command stops with "The server at", the server's address and "needs a sign-in: run athenode init --server <url> in a terminal to sign in (or, without a browser such as in CI, set ATHENODE_PRO_TOKEN to a personal access token from your Account page on the server)."

Run the CLI in CI with a personal access token

A job without a browser, such as a CI pipeline, cannot sign in through the browser. It uses a personal access token instead: a token you create for yourself on the Account page of the Pro server. The token acts as your account, with your project roles, until it expires or you revoke it.

Create a personal access token

Open the user menu and select Account.
Under Access tokens, enter a Name that says what the token is for, such as the CI pipeline of a repository.
In Expires, choose In 30 days, In 90 days, In 1 year or Never. In 90 days is preselected.
Select Create token.
Pro shows the token, which starts with athpat_, and "Copy the token now: it is not shown again." Select Copy and store the token in your CI system's secret variables, never in the repository.

Pro cannot show the token again. If you lose it, revoke it and create a new one. An account has at most 50 tokens, expired ones included, and creating one more stops with "An account has at most 50 access tokens: revoke one first". Single sign-on accounts create tokens the same way.

Use the token in a job

Set ATHENODE_PRO_TOKEN to the token in the job's environment, from the secret variable that holds it:

ATHENODE_PRO_TOKEN="$ATHENODE_PRO_TOKEN_SECRET" athenode sync

The CLI sends the token in place of its stored sign-in, for init, sync and athenode project. It never renews the token and never opens a browser. When the server refuses the token, because it is unknown, expired or revoked, the command stops with "The server at", the server's address and "refused the token in ATHENODE_PRO_TOKEN (unknown, expired or revoked): create a personal access token on your Account page on the server and set ATHENODE_PRO_TOKEN to it."

The token also works for the Athenode MCP server of the project. An AI tool in a job that cannot sign in through the browser sends it in an Authorization: Bearer <token> header of its MCP entry, from a variable of the job's environment. Its calls are allowed or refused by your role in the project, as for any sign-in.

See and revoke your tokens

The Access tokens list on the Account page shows each of your tokens with its name, then "Created" with the date, "last used" with the date or "not yet", and "expires" with the date or "Never". A token past its expiry date is marked Expired and stops working. It leaves the list 30 days after it expired.

To revoke a token, for example when a job no longer needs it or the token may have leaked:

On the Account page, select Revoke in the token's row.
Confirm with Revoke.

Pro shows the token's name and "is revoked." Every request with the token is refused from then on, and a job that sends it stops with the message above. Revoking cannot be undone.

An administrator can also revoke one of your tokens, for example when it may have leaked, on the Users page, as Users and sign-in describes. The token then leaves your list, and you keep your account and your other tokens. When an administrator disables your account, your tokens stop working at once and are deleted, and you create new ones once the account is enabled again.

Tokens are created only on your own Account page, and revoked there or by an administrator on the Users page, in the browser: a token cannot create or revoke another token.

Sign the CLI out with athenode logout

Sign out when you leave a project for good or when you no longer use the machine. In a repository bound to a Pro server, run:

athenode logout

The CLI ends the sign-in at the server and forgets it on this machine, then prints "Signed out of", followed by the server's address. When the server cannot be reached, the sign-in is forgotten on this machine all the same. Elsewhere, name the server:

athenode logout --server https://athenode.example.com

Without --server outside a repository bound to a Pro server, the command stops with "This repository is bound to no Pro server: name one with --server <url>." When there is nothing to forget, it prints "Not signed in to", followed by the address. If ATHENODE_PRO_TOKEN is set, the CLI adds a note that the variable goes on sending its token. The next command that needs the server signs you in again.

Connect your AI tools to a project on Pro

init writes the Athenode MCP server into each AI tool you selected, pointed at the project on the server: https://athenode.example.com/api/mcp?project=<id>, followed by the MCP modules you chose. The Athenode MCP server is the server through which your AI agent reads and changes the project's specifications, ToDo cards and plugins and works on its SSH connections. The entry holds no token.

Follow the steps init printed under "Still to do in your tools:", such as approving the project's MCP servers.
Start your AI tool in the repository.
When the tool first connects, it opens the browser on the server's sign-in. Sign in if the browser has no session on the server.
On the consent page, check the name and the address of the application, then select Allow access.

The tool then calls the Athenode MCP server as your account. Every call is allowed or refused by your role in the project, and a call to a project you have no role in is refused.

The consent page appears each time an application signs in to the server, the Athenode CLI included. Its heading asks whether to allow the application, by the name it gave itself, to use Athenode Pro. An application without a name appears as "An unnamed application".

"Signed in as", followed by the email of the account that grants the access.
"The application sends you back to", followed by the address the browser goes to after your decision, shown prominently.
A warning that depends on that address. For an address on your own computer, such as the sign-in of the CLI or of Claude Code, the page says that an application running there receives the access. For an address with a scheme of an application, such as Cursor's cursor://, the page shows the scheme with the host, such as cursor://anysphere.cursor-retrieval, and says that the application installed for that address receives the access. For any other address, it asks you to continue only if you recognise it.
The scope mcp, and the fact that the application registered itself and its name is not verified.
Allow access and Deny.

Allowing lets the application use the server under your account, within the roles you have in its projects. Continue only when you started the sign-in yourself, a moment ago, from a tool you trust. A sign-in request is valid for 10 minutes. After that, or once it was used, the page shows "This authorization request expired", and you start the sign-in from the tool again.

Add the Athenode MCP server to another AI tool

Add the server by hand to an AI tool that init did not install into. Every address names a project with ?project=<id>: a Pro server refuses a connection without it.

Open the project in the web UI and select Project settings in the sidebar.
Under MCP clients, select Copy the MCP URL.
Add the server to your AI tool under the name athenode, with the HTTP transport and the copied address. For Claude Code:
```
claude mcp add --transport http athenode "https://athenode.example.com/api/mcp?project=<id>"
```
Connect the tool and allow it on the consent page.

An administrator can print the snippets for Claude Code, Cursor, VS Code and other clients on the server, for one project:

athenode-pro mcp-config --project <id>

--client claude-code, cursor, vscode or json prints one snippet alone. --public-url sets the address when the server's configuration does not hold it. The command writes nothing. Projects describes the project settings, and the Athenode MCP server the entry each client reads.

An AI tool signs in to Pro when it supports the MCP sign-in through the browser. The server accepts a tool under these conditions:

The address the tool asks the browser to return to is an https address, an http address on your own computer (127.0.0.1, [::1] or localhost, on any port), or an address with a scheme of the tool's own, such as Cursor's cursor://. An address that the browser or the operating system itself handles, such as a javascript:, data:, file:, smb: or ms-msdt: address, is refused, and so is an address with spaces or control characters.
The tool runs outside the browser. MCP clients that run inside a web page cannot connect.
One network address can make at most 20 registrations an hour. Beyond that, registration is refused until the hour has passed.

Goose receives no Athenode MCP server from init, as supported AI tools lists.

How long an AI tool stays signed in

An AI tool renews its sign-in by itself while you use it. A sign-in that has not been renewed for 30 days ends, and every sign-in ends 90 days after you allowed the tool. The tool then asks you to sign in again. A renewal works once. If two copies of a tool renew with the same sign-in at the same time, the server ends that sign-in and both ask you to sign in again.

Access also ends in these cases:

What happens	Effect on the AI tool
An administrator revokes the tool on the MCP clients page	Every sign-in of the tool ends at once. The tool must register again and be allowed before it reaches the server
An administrator disables your account	Every sign-in of your AI tools and of the CLI ends at once, and your personal access tokens are deleted
An administrator revokes one of your personal access tokens on the Users page	Every request with that token is refused at once. Your other tokens and sign-ins keep working
An owner removes your role on the project	The next call to that project is refused
The server's licence stops being active	Every call is refused until a valid licence key arrives, as the Pro licence describes

Users and sign-in describes disabling accounts.

Manage MCP clients as an administrator

An MCP client is an AI tool, or the Athenode CLI, that registered itself to sign in to the server. Each installation registers once, at its first sign-in. Administrators see and revoke the clients on the MCP clients page, under Administration in the sidebar outside a project.

Column	What it shows
Client	The name the client gave itself, or Unnamed, with its client id and, when it sent them, its software id and version
Redirect URIs	The addresses the client may send the browser back to
Registered	When it registered, and from which network address
Last used	When it last used the server
Live grants	How many sign-ins of the client are active
Status	Active or Revoked

To revoke a client:

On the MCP clients page, select Revoke in the client's row.
Confirm with Revoke.

Every token issued to the client stops working at once, and its live grants end. The client must register and be allowed again before it reaches the server. A revoked Athenode CLI registers again by itself at its next sign-in. Revoking cannot be undone.

The server removes a client that never signed in after 7 days, and a revoked client after 30 days. While no client has registered, the page shows the address to point Claude Code, Cursor or VS Code at.

Move a local project to Athenode Pro

A project archive carries a project of your daemon to a Pro server as a new project, with new ids. Export the project from the daemon, then import the archive in a repository bound to the Pro server, or with Import archive on the Projects page of the Pro web UI. Any account can import, and the importing account becomes the owner of the new project. Against a Pro server, athenode project import uses the CLI's sign-in and signs you in through the browser when there is none. Move a project to another server gives the steps, and Projects what an archive holds.

The public Athenode plugin package on Pro

The public Athenode plugin package, from the Claude Code marketplace, reaches the local daemon only. On a repository bound to a Pro server, init and sync always replace it with your project's plugin and print a note for each AI tool where they do. The public package is turned off in the tool's local settings file only. init --public-plugin keep stops with an error on Pro. Install a plugin describes the choice on the daemon.

Last updated: 2026-10-29