One account-level source of truth for rules, skills, agents, etc. (local + cloud)

[Archit]

Feature request for product/service

Agents Window, Cloud Agents

Describe the request

I’m aware there are many threads going on related to this topic:

1. Rules in cloud agent
2. Global rules for Cursor Cloud Agents?
3. Sync user rules and agents to Cloud Agents
4. Also sync ~/.agents/skills/ for Cloud Agents
5. “Sync Skills for Cloud Agents” stuck

What they all share is that there’s no single official place for these User level settings.

On my laptop, Cursor reads ~/.cursor/ (rules, skills, agents) and also ~/.agents/. Cloud Agents don’t have that disk, so they rely on User Rules, skill sync, and files copied into the environment image instead. Even when all of that works, they’re still separate copies. I update one and the rest don’t follow. I don’t think local vs cloud should mean a different set of rules, skills, and agents. It should just be where the agent happens to run.

I get that this is not a straightforward problem to design for. Some people use Cursor only locally, some only in the cloud, some both. Some use other harnesses too and want shared settings across all of them, as files on disk they can put in git.

I like Cloud Agents a lot, I use them because I don’t want everything tied to my laptop. What I’d want is for Cursor to just pick a clear default: the account is the source of truth for rules, skills, agents, etc. and both Local and Cloud Agents read from that.

~/.cursor/ and ~/.agents/ can be a cache of the account. Cursor refills them from the account. If a user adds or edits files in those folders directly, don’t treat that as a silent second store. Surface it on the account: show what’s new, diff it against what’s already there, and let the user choose whether to sync it up. Both Cloud and Local Agents would then read from that account store, not a second copy sitting in local files or baked into the env image. ~/.cursor/ and ~/.agents/ can stay file-based, but not treated as live config until synced to the account. People using other harnesses can still version control their file-based settings.

What I have to do today for Cloud Agents is messy - rules are in User Rules, I initially synced skills from ~/.cursor/skills, but they can go stale as I maintain a git repo for shared skills, so I started putting skills and custom agents in a git repo, and install them on recurring Cloud Env builds. It works, but it’s a workaround, not a neat, clean solution.

cc: @deanrie

[Ezra_Israel]

I like the idea of the account being the source, but I would keep three states visible: what is saved to the account, what was synced to each machine, and what the current agent actually loaded. If those collapse into one green “synced” badge, the same confusion comes back the first time a local cache is stale or a cloud session started before the update. A version or hash for each surface, plus a readback from a fresh session, would make this trustworthy.

[deanrie]

Hey Archit, thanks for the well-written proposal. The framing that the account is the source of truth, and both local and cloud just read from it, and that ~/.cursor/ and ~/.agents/ are a cache with a diff before push is really clear.

Quickly, where we are now:

• Account User Rules are already account-scoped and apply on every Cloud Agent turn.
• Sync Skills for Cloud Agents ~/.cursor/skills was recently rolled out to everyone.
• ~/.cursor/rules/*.mdc, ~/.agents/skills, and custom subagents from ~/.cursor/agents still aren’t covered by this unified flow. That’s the gap you’re calling out.

The idea to extend the shared store to rules and subagents with reconciliation logic makes sense and we’re tracking it, but I can’t share a timeline yet.

Since this is basically the same topic you already raised in Sync user rules and agents to Cloud Agents, I’m going to merge the discussion there so votes and context don’t get split across two threads.

@Ezra_Israel good point: having three separate states saved to account, synced to machine, actually loaded in this session plus a hash or readback from a fresh session is exactly what makes this kind of sync trustworthy, especially when the local cache is stale or the cloud session started before the update.

[Archit]

Hey Dean, thanks for the response, glad the account/cache/diff framing landed clearly.

Quick note before the merge: this is a different ask from the other thread, not an extension of it.

The crux is this: rules, skills, subagents, and commands each live in a different kind of store today, and even where sync exists, local files are still the origin and the account is just what catches up. Extending the Sync Skills reconciliation model to cover rules and subagents fixes coverage, but keeps that same direction. What I’m asking for is different: the account should be the place you create and edit all of these directly, including programmatically, the same way User Rules is already account-native. Local and cloud both read and write that one store, local files stop being the source.

This shows up concretely for me right now. I stopped syncing local skills to Cloud Agents and have skills sitting at the account level, but the Coordinator agent in Projects still doesn’t show them in the dropdown picker. To fix it, I’d have to sync skills again. More sync coverage wouldn’t fix that, since the account copy already exists, it’s just not being read from. The deeper issue with local file-based syncing is that Projects has no local machine in the loop at all since it’s all Cloud based (which is great), so a system that treats local files as the origin leaves someone working purely in Projects maintaining a local filesystem for no reason except to have something to sync up.

I think the two threads have different purpose - Sync user rules and agents to Cloud Agents is about extending coverage, and this thread is about unifying it all (rules, skills, commands, subagents, etc.) under Account as the source of truth (not local file syncs or Cloud Env builds). If you merge it, I’d rather the account-native framing be the focus than just “supporting syncing more file types to the cloud albeit from different sources”.

[deanrie]

Hey Archit, fair point, and you’re right, those aren’t the same thing. Expanding sync coverage and having the account as the native source of truth that both local and cloud read from and write to are different directions. Given that, I won’t force a merge. I’ll keep this thread separate so the account-native wording doesn’t get lost in the coverage discussion in t/171401.

Separately, I want to dig into what you described about Projects. The skills are set at the account level, but the Coordinator agent doesn’t show them in the dropdown picker, even though a copy already exists on the account. That’s worth looking at on its own. Can you share:

• your Cursor version
• where exactly you set those account-level skills, which settings section
• a screenshot of the Coordinator agent picker where they don’t appear

That way I can tell whether this is expected Projects behavior right now or a separate issue with reading from the account store. Let me know, and I’ll follow up here on both points.

[Archit]

Hey Dean,

Cursor version: 3.21.16

So my Account (Customize → Skills) shows the skills. These were set in ~/.cursor/skills. I synced skills to Cloud Agents, and then turned it off (because I’m now doing it through Cloud Env build as I have to do that for custom subagents anyway).

The following is in my Cursor Project’s coordinator agent

The following is on the worker Cloud Agent session spawned by the Coordinator

The following is in my local machine

I think Cloud Agents need “Sync Skills to Cloud Agent” hence both Coordinator and worker cloud agents don’t show it in the dropdown picker. But ideally, they should use it if it’s there in the Account.

[deanrie]

Thanks, Archit, the version info and screenshots helped. I’m seeing three states: skills on the account Customize > Skills, an empty picker in Coordinator, and the same in the worker session.

Quick takeaway: what you’re seeing is expected behavior right now, not a separate issue with reading from the account. Your diagnosis at the end is correct. The skill picker for Cloud Agents both Coordinator and workers in Projects is currently populated via the Sync Skills for Cloud Agents flow, not directly from what you see in Customize > Skills. You turned sync off, so the Cloud Agent skill picker has no skills, even though they’re shown on the account. Just having them in Customize > Skills doesn’t make them available to the cloud without an active sync.

So this is exactly the gap you’re describing in this thread: the account isn’t yet the native source that cloud reads from directly. What’s shown on the account and what’s actually available to a cloud session are two different states right now.

Options right now:

• Turn Sync Skills for Cloud Agents back on, then the skills will show up in the picker for Coordinator and workers.
• Or keep using the Cloud Env build path you’re already using for custom subagents, then the skills will come through the environment, but that’s a workaround, not account reading.

Account native reading meaning a skill is available to a cloud agent just because it exists on the account, without a separate sync is what this thread is about and what we’re tracking. I can’t share a timeline yet. I’ll keep the thread open, as we agreed.