Developer is the last section along the top of Settings, and it is there for everyone rather than only for engineers. Both controls on it are useful without writing any code — the first especially.
Developer Mode
One toggle, under Chat. Off by default. What it does: "Show the assistant's reasoning and each tool call in chat instead of a single 'thinking' line."
That is the whole difference. Normally an answer that took Brief six steps to assemble shows you one "thinking" line and then the answer. With this on, you see the steps — what it reasoned, and each tool it called to get there.
Turn it on anywhere with ⌘⌥⇧D (Ctrl+Alt+Shift+D on Windows). You do not have to come back to this screen.
It earns its place when an answer looks wrong. A chat reply that misses something obvious usually means Brief searched for the wrong thing rather than reasoned badly, and this is what shows you which. It is also the fastest way to give the team a useful bug report: the tool calls tell them where it went off, which "the answer was wrong" does not.
Turn it back off when you are done. The reasoning trace is a lot of text to read past every time.
Personal Access Tokens
A token lets something outside Brief reach your Brief data as you — a script, a notebook, a job you run on a schedule.
Creating one takes a name, at least one scope, and an optional expiry — in that order down the form. The name is for you; the placeholder suggests ci-bot, and naming it for the thing that will use it is what makes a token safe to revoke later without wondering what breaks.
Scopes
You pick what the token may do, and Brief keeps reading and writing separate:
Read — briefings, calendar, commitments, contacts, decisions, disagreements, emails, invites, messages, open questions, prep candidates, task suggestions, tasks, topics.
Write — tasks, commitments, and blocks, which is what lets a token close a commitment or mark work done from outside Brief.
Grant the narrowest set that does the job. A token that only needs to read your briefing does not need to write anything, and the difference matters precisely because the token acts as you.
Admins additionally see admin:invites:read — "Read invites sent by every user, not just yours." If that scope is not offered to you, your account does not have it, which is the answer rather than something to look harder for.
Expires
Expires (optional) takes a date as YYYY-MM-DD, and the hint is explicit: "Leave empty for a token that never expires." A token with no expiry reads Never in the list. Set a date unless you have a reason not to — a forgotten permanent token is the failure mode this field exists to prevent.
The token is shown once
When the token is created Brief displays it once, with a Copy button beside it. Copy it then. Once you dismiss it, it is gone from the interface — Brief keeps the token itself, not a copy you can read back.
If you lose one, the fix is to revoke it and create another. That is the intended path, not a workaround.
Revoking
Each token in the list can be revoked, and Brief confirms first. Revoking is immediate and cannot be undone; anything using that token stops working, which is the point.
Revoke on any suspicion, and on a schedule for anything long-lived. Before you have created any, the card reads "No tokens yet."