ChatGPT and Cursor on your server: share links and access

The short version: on the Console tab of a RE:NODE server there is a bar called "Work on this server with AI". You pick what the assistant is for, press Connect AI, and the panel copies a private link to your clipboard. Paste that link into ChatGPT, Claude or any assistant that can open a URL, and it reads a description of your server written for it: the runtime, how the server boots, what the pre-flight check found, what you asked it to help with. By default the link is read-only. Pick "Manage this server" and it becomes a link that can act - start, stop, restart, type into the console, edit files. No API key is created or copied at any point. Links stay alive while they are used and die on their own when they are not, and every link you have handed out is listed under Account -> Connected AI, where one click revokes it.

Cursor works differently, because Cursor lives in your repository rather than in a chat window. The panel can open a pull request that writes the server's rules into AGENTS.md, CLAUDE.md and .renode/server.md, and Cursor reads those on its own. The rest of this post is how each path works, what a link can and cannot reach, how long it lives, and how to take access back.

Three ways to hand a server to an assistant#

There are three separate mechanisms, and it helps to know which one you are using before you paste anything anywhere.

The share link is the universal one. Almost every assistant can open a web page, so a URL is the lowest common denominator, and it is the path we confirm for ChatGPT. The MCP connection is a proper tool connection: the assistant gets named tools such as reading the console or writing a file, instead of a document to read. We built and tested that path against Claude (Claude Code and Claude.ai custom connectors); other clients that support remote MCP over Streamable HTTP should be able to use it, but we have not tested ChatGPT or Cursor against it specifically, so treat that as your own experiment. Repository context is the quiet one: no link at all, just files in your repo that coding assistants read by convention.

You can use more than one. A common split is a read link pasted into a ChatGPT conversation to ask "why is this not starting", and repository context so Cursor writes code that binds the right port in the first place.

Making a share link from the Console tab#

The bar sits above the terminal on the Console tab, and also on the Startup tab. It has one dropdown, "What the assistant is for", and one button.

1. Open the server and go to the Console tab.
2. In "What the assistant is for", choose the purpose. The table below lists them.
3. Press Connect AI. The panel makes the link and copies it.
4. Paste it into the assistant with your question.

"Server won't start" is the odd one out on purpose. A crashing server's most useful evidence is the last screen of console output, so instead of a link the panel copies a ready-to-paste prompt with that output already in it. Use it from the Console tab so the console tail is included. It is the fastest way to get a second pair of eyes on a crash loop; the crash loop guide covers what to look for yourself first.

The link itself is shown once. The panel stores only a hash of it, the same way a password is stored, so nobody can read it back out of the panel later - including us. If you lose it, make a new one. If your browser blocks clipboard access, the panel shows the link in a box so you can copy it by hand.

The link looks like this:

https://panel.renode.space/ai/rnai_<48 random characters>

A link that can act also comes with an MCP address, which is the same URL with /mcp on the end. More on that below.

Read links and links that can act#

The difference between the two kinds of link is the whole security model, so it is worth being precise.

A read link reaches the server's context (runtime, boot order, pre-flight findings, which variables exist), the task prompts, the console tail and directory listings. It does not reach file contents. That is a deliberate line: a read link survives a week without use and gets pasted into chat histories, a .env file is where secrets live, and we would rather an assistant ask you to paste a file than have a week-old link read it.

A link that can act - the "Manage this server" purpose - reaches everything a read link does, plus:

• start, stop, restart and kill;
• typing commands into the console;
• reading and editing files.

Some things are not reachable through any link, of either kind: deleting or renaming files, reinstalling, changing the startup command or variables, databases and their passwords, backups, schedules, users, SFTP details and API keys. A link cannot list your other servers or see the list of links. Writes are text only, at most 1 MB per file, and never anywhere under .git/, because .git/hooks is code that runs on the next fetch.

A link that can act is a key to the server for as long as it lives. Whoever holds the URL can restart the server and edit its files - no password, no second factor.

That is not a design flaw, it is the point: you are pasting it into a program that has none of those things. It is also why the link that can act lives a day, not a week, when unused (see the expiry section). Treat it the way you would treat an SFTP password: paste it into a conversation you control, not a shared channel, and revoke it when the job is done.

Permissions are checked twice on every call. The link has to allow the action, and the person who made the link has to still hold that permission on that server, right now. A subuser who can only use the console cannot make a link that restarts the server. If you take a permission away from a subuser, their links lose it on the next call. That fits neatly with least-privilege subusers: give a teammate console-only access and the links they make are console-only too. The roles and teams side of that is in the guide.

Every action taken through a link is recorded in the server's activity log as the person who made the link, marked as coming from an AI link. A restart an assistant asked for counts as a restart you asked for, so it does not count towards the crash watcher's restart limit.

Rate limits on a link

An assistant stuck in a loop of "restart and check" hits the power limit long before it does damage, and gets a readable error it can report back to you.

Using a share link with ChatGPT#

With ChatGPT the share link is the whole setup. There is nothing to install and no key to create.

1. Make a link for the purpose you need, usually General or Fix my repository.
2. Start a conversation and paste the link with a plain request: "Read this and tell me why the server exits after start."
3. Let it open the page. The page starts with a header saying it is a RE:NODE server, that nothing secret is in it and where the passwords actually live, then the server's details, then the task prompt.

What ChatGPT can do with a link depends on what tools it has in that conversation. Opening a web page is a GET request, and on a link GET never changes anything - so link previews and crawlers that fetch the URL cannot restart your server. Acting on the server needs POST requests or an MCP connection. An assistant that can only browse will read even a link that can act and then tell you what to do rather than do it. That is often what you want anyway.

If the assistant says it cannot open the link, open it in your own browser: it is a plain markdown page, and you can paste its text into the conversation. Opening it yourself counts as a use, so it also extends the link's life.

A link that can act describes its own doors at the end of the document, under "Acting on this server": the MCP address and the HTTP endpoints this particular link may use, with curl examples. A read link says it is read-only instead. The HTTP side looks like this:

$ curl -s -X POST -H 'Content-Type: application/json' \    -d '{"signal":"restart"}' \    https://panel.renode.space/ai/rnai_.../api/power

Answers come back as {ok, result} or {ok: false, error: {status, message}}, so a script or an assistant can tell success from refusal without guessing.

Editing a .env without exposing it

Assistants are bad at .env files for a specific reason: the panel redacts secrets in everything it hands out, so an assistant that reads a .env, changes one line and writes the whole file back would replace every password with the redaction placeholder. A link that can act therefore has a separate write-only tool for .env* files. It takes key names to set or unset, makes the change on the panel side, keeps every other byte, and returns only key names. You can tell an assistant "set DATABASE_URL to this value" and nothing about the file's other contents comes back. The general rules for what belongs in that file are in environment variables and secrets.

Using Cursor: repository context and links#

Cursor is an editor with an agent in it. It works on the code in your repository, and the useful thing to give it is not a description of a running server so much as the server's rules: which port to bind, how the server boots, which runtime version it runs.

If your server deploys from GitHub (app lines only, see deploying a Node app from GitHub), switch on "Keep AI context in the repository" on the GitHub tab. The panel's GitHub App then opens a pull request that adds:

• .renode/server.md, a file the panel owns and says so;
• a marked block in AGENTS.md;
• a marked block in CLAUDE.md.

Cursor, Claude Code, Copilot and Codex read those files on their own, so an agent opened in the repository knows how the server runs without anyone pasting anything. In AGENTS.md and CLAUDE.md only the text between the markers is ever replaced, and whatever you wrote around them is left alone:

Your own notes for agents stay here.<!-- renode:start -->(the panel's block - replaced on each refresh)<!-- renode:end -->

A few properties worth knowing:

• The panel never pushes to your deploy branch. It commits only to its own renode/ai-context branch and opens a pull request; you merge it. Pushes to that branch never trigger a deploy.
• A public repository gets the rules and none of the particulars: no address, database host, usernames, domains or variable values. Anything GitHub does not explicitly report as private is treated as public.
• It refreshes at most every ten minutes and only when the content actually changed, so it does not spam you with pull requests. Update now on the GitHub tab forces a refresh.
• Switching it off closes the pull request and deletes the branch. It never touches what you already merged.

You can also paste a share link into Cursor's chat like any other assistant. Cursor's agent can run terminal commands, so with a link that can act it can use the curl examples from the link's document - and Cursor asks before it runs a command unless you have told it not to. Leave that confirmation on. The reasoning is the same as in our notes on AI agents and servers: the agent proposes, you read the command, then it runs.

Keyless setup: no API key to copy#

The panel still has classic API keys (the ptlc_ kind under Account -> API Keys), and they still work on the MCP endpoint. But a key has to be created, copied, pasted, and then lives until somebody remembers to delete it. None of the AI paths need one.

• A share link is a credential in itself, scoped to one server and one purpose, and it expires on its own.
• Repository context needs no credential at all on the assistant's side.
• The MCP connection signs in with OAuth.

The MCP endpoint is https://panel.renode.space/api/client/mcp. Add the bare URL to an assistant that supports remote MCP - for Claude Code that is one command:

$ claude mcp add --transport http renode https://panel.renode.space/api/client/mcp

The assistant opens a browser at the panel's consent page (in English or Georgian, by your account's language). You approve once and choose two things: which servers (all of yours, or a pick) and a level. Files allows reading and editing files and the console. Manage adds start, stop and restart. Neither level reaches databases, backups, schedules, users, startup settings or account settings. "All my servers" means servers you own or are an unexpired subuser on.

After that the assistant keeps its own access alive. Access tokens last an hour and are renewed in the background; the renewal token lasts 30 days and slides with use, so an assistant you use once a month does not ask again. If a spent token is ever replayed - the sign of a stolen copy - the whole grant is revoked.

A link that can act has its own MCP address, the link URL with /mcp on the end, which pastes into Claude.ai as a custom connector as it is:

$ claude mcp add --transport http renode-link https://panel.renode.space/ai/rnai_.../mcp

The difference: the OAuth connection is tied to your account and the servers you picked, and lasts while it is used; the link's MCP address is tied to one server and dies with the link.

Sliding expiry and rotation#

Nobody picks a duration for a share link, and there is no list on the server to clean up. A link keeps itself alive while it is used and lapses when it is not.

Every successful use - the page opened, an HTTP call, an MCP call - pushes the expiry out to the full idle window again. The ceiling never moves, so even a link in constant use eventually ends and you make a fresh one. The link that can act is short on purpose: a credential that outlives the conversation it was made for is the one somebody finds in a chat log a month later, and one still being used is by definition still in that conversation.

Rotation replaces deletion. Making a new link for the same server and the same purpose revokes your previous one in the same step, so pressing Connect AI again is how you replace a link you pasted somewhere you regret. There are caps behind that as a safety net: at most five active links per server, of which at most two can act. Making a sixth, or a third that can act, retires the oldest.

A link also stops working the moment the person who made it loses access to the server. Remove a subuser, or let their time-boxed access run out, and every link they made dies with it - nobody has to remember the links exist. A suspended server answers nothing through any link.

Every refusal looks the same: a plain 404. Expired, past its ceiling, revoked, replaced, server suspended, creator removed - the assistant cannot tell which, and neither can anyone holding a leaked copy. The page header warns the assistant that a link lapses when idle, so a decent assistant will tell you the link expired rather than inventing a reason.

The Connected AI page and revoking access#

Account -> Connected AI (/account/ai) is the one place that shows everything you have handed out. It has two lists.

Connected assistants lists every assistant you approved through OAuth: its name (and, for some clients, the host that published it), when you approved it, when it was last used, which servers it covers and at which level. Each has a Disconnect button. A disconnected assistant loses access at once; to use it again you connect it again and approve it in the browser.

Share links you made lists every active link you created, on any server: the server, whether it is "Read only" or "Can act", when it expires, how many times it was opened and how many actions it has taken, and when it was last used. Each has a Revoke button. A revoked link stops at once on every door - the page, its MCP address and its HTTP API.

Revoking needs no permission on the server itself. If your access to a server was reduced but your link is still listed, you can still revoke it: taking back what you handed out only ever reduces access.

When to use it:

1. You pasted a link that can act into a conversation that might be shared or exported. Revoke it.
2. The "opened" count is higher than you expect. Revoke it and make a new one - a fresh link replaces the old one anyway.
3. You stopped using an assistant. Disconnect it, rather than waiting 30 days for it to lapse.
4. Someone left the team. Removing them as a subuser already kills their links, but check the list on your own account too.

The warning under the bar says this in short: a link that can act stops working if unused for a day, and you can disconnect it sooner from Account -> Connected AI.

What the assistant never sees#

Every byte that leaves through a link, a prompt or the MCP endpoint passes a redactor with three layers. By name: any variable called something like TOKEN, PASSWORD, KEY, SECRET, AUTH or SALT has its value withheld. By shape: GitHub, Slack, OpenAI and AWS keys, JWTs, passwords inside URLs and long random-looking strings are withheld whatever they are called. By value: the server's actual secrets and database passwords are collected and scrubbed out of the finished output, which is what catches a password pasted into a variable called NOTES. Database passwords are never put into the output in the first place.

The honest wording is that passwords and tokens are withheld, not that an assistant can never see a secret. Redaction is a net, not a promise. If you echo a secret to the console in some format nobody anticipated, or keep one in a file a link that can act opens, assume it may reach the assistant. Keep secrets in environment variables and .env, and never print them in logs. The console guide and reading the console are worth a look if your app prints its configuration at boot.

Troubleshooting#

The link returns 404. It expired, hit its ceiling, was revoked, was replaced by a newer link for the same purpose, or the server is suspended, or you lost access. Make a new one from the bar; there is no way to revive an old one, and the 404 deliberately does not say which.

The assistant says it opened the link but describes the wrong server or invents details. It may not have fetched the page at all and answered from guesswork. Ask it to quote the first line of the page. If it cannot, open the link yourself and paste the text.

The assistant reads files on one server but not another. A read link never returns file contents, and on any link the permission check runs against the person who made it. If a subuser made the link and has no file access, neither does the link.

An action is refused with a rate limit error. The link hit 60 requests, 20 actions or 6 power actions in a minute. Wait a minute, and look at why: an assistant restarting a server six times a minute is not fixing anything.

A file write is refused. Check that it is text, under 1 MB, and not under .git/. Deleting and renaming are not available through any link at all; do those in the file manager.

Cursor does not seem to know the server's rules. The context pull request has to be merged into the branch Cursor has open. Check the pull request from renode/ai-context on GitHub, and press Update now on the GitHub tab if you changed something in the last ten minutes.

FAQ#

Can ChatGPT restart my server with a share link?

Only if it can send POST requests or connect over MCP in that conversation. Opening a link is a read and changes nothing. A browsing-only assistant reads a link that can act and tells you what to run instead of running it.

Do I need to create an API key for any of this?

No. Share links, the OAuth connection and repository context all work without one. Classic ptlc_ API keys still work on the MCP endpoint if you prefer them, but then deleting the key when you are done is your job.

How long does a share link last?

A read link lasts 7 days after its last use, up to 90 days from creation. A link that can act lasts 24 hours after its last use, up to 30 days. Use resets the idle clock; nothing resets the ceiling.

Can a link delete my files or my database?

No. No link can delete or rename files, reinstall the server, touch databases or their passwords, change backups, schedules, users or startup settings, or read SFTP details or API keys.

What happens to my links if I remove a teammate?

Every link they made stops working on its next use, because each call checks that the creator still has access to the server. Their OAuth connections lose that server for the same reason.

Does RE:NODE run the AI model?

No. We run no model. The panel only builds the page, the tools and the access rules your own assistant uses.