dots custom rules: how they work

Custom rules define three things about each supported action: whether your dot may take it alone, whether it needs your approval, or whether you have to do it yourself. You configure them under Customize → Custom rules, and they cannot disable OpenAI’s safety requirements.

The four behaviours

Each rule is written by describing the action and choosing one of these behaviours:

Behaviour	What it means
Take action without asking	The dot acts on its own, without consulting you
Take action if pre-approved	It acts on its own when you explicitly requested that action
Ask before taking action	The dot checks with you every time
Hand off to you	The dot does not do it: it leaves it for you to complete

How to write a rule that works

The most common mistake is writing vague rules. “Do not do risky things” tells the dot nothing. A useful rule names a concrete action and a concrete behaviour.

Examples that work:

• “Never send emails” → block explicitly.
• “May read my calendar without asking” → without asking.
• “Before publishing anything, ask me” → ask before.
• “Payments are mine to make” → hand off.

The key distinction: pre-approved is not standing permission

This is the most misunderstood point. Approving one message does not give your dot ongoing permission to contact people on your behalf.

If you want to authorize something in advance, you have to be specific. For a future message, the rule should include:

• Who it goes to.
• What it should say.
• When, or under what conditions, it should be sent.

Any advance approval stays limited to exactly what you authorized, and nothing more.

What your rules cannot do

This matters as much as what they can. Custom rules cannot:

• Override core safety requirements. Changing a password always stays with you, no exception.
• Change Auto-review. The pre-action review system is independent of your rules.
• Lift the proactive research restrictions. In the background the dot only reads, and that is not configurable.
• Turn into action permissions. A rule defines behaviour over supported actions; it does not unlock new capabilities.

The order of the layers

Understanding the order prevents frustration:

1. OpenAI’s safety requirements — always apply, cannot be disabled.
2. The dot’s built-in rules — default behaviour for actions that need confirmation, advance approval, or none.
3. Your custom rules — sit on top of the previous two and adjust them within what is allowed.

If a rule of yours seems “not to work”, it is almost always colliding with layer 1 or 2.

Common mistakes

Mistake	Why it hurts
Writing vague rules	They are not evaluable; the dot falls back to default behaviour
Setting rules after connecting apps	The exposure window already existed
Authorizing “in general”	A generic approval does not cover concrete cases
Blocking everything out of caution	The dot becomes useless: it can do nothing without you
Not checking the activity view	No way to tell whether the rules are working

A reasonable starting point

If you do not know where to begin:

• Reads: without asking. Being able to consult your data is the basis of it being useful.
• Anything leaving your account: ask before. Messages, posts, sends.
• Credentials and payments: hand off to you. That is what OpenAI does by design anyway.
• Data deletion and software installs: ask before. These may need approval each time.

After your first real assignment, adjust. Rules are better written knowing how the dot works in practice than in the abstract.