Audit log and Buff Code
What around Buff Code goes into the audit log: device sign-in and revocation, viewing others’ sessions, exports, questions, knowledge — with severity.
The organisation’s audit log records people’s actions around Buff Code. The contents of the sessions themselves — the model’s requests and answers — do not go into it: that is what session records are for, and the log answers the question “who did what”.
What is recorded
| Event code | What is recorded | Severity | When |
|---|---|---|---|
session.device_approve | Buff Code device sign-in allowed | notice | a person clicked “Allow sign-in” on the sign-in page; the event has the device name and the organisation |
session.device_deny | Device sign-in denied | notice | a person clicked “It wasn’t me”; the event has the device name |
session.device_revoke | Device revoked | notice | the “Revoke” button on the sign-in page; the event has the device |
session.device_refresh_denied | Device token refresh refused | warning | only on refusal: the device is already revoked, the signature did not match or the person has no access left |
session.device_reuse_revoked | Device revoked: refresh token reused | warning | an already spent token was presented again — this happens when a token is stolen; the device is revoked immediately |
ide.session_view | Someone else’s development session viewed | notice | the owner opened another developer’s session |
ide.session_export | Development session exported | notice | any Markdown or JSON export, of your own session or someone else’s |
ask.create | “Ask” conversation about development sessions created | info | a question about sessions; the details hold the identifiers of the sessions in the set |
knowledge.create | Knowledge “…” created from Buff Code | info | the developer confirmed an entry proposed by the model |
The full catalogue with operation and severity — Event catalogue.
Viewing and exporting: how they are counted
- One entry per read, not per page. A long session arrives in the workspace in pages; “Show more” and the tail appended by “Follow” do not create new entries. One entry — one opening of the session.
- Viewing your own session is not an event. The session list and viewing your own session are reading
what is yours; they are not recorded. Only the owner can open someone else’s session, so
ide.session_viewis always an owner’s action. - An export is always recorded — of your own session too: the file leaves the workspace.
- A refusal is recorded too. A member who tried to open someone else’s session leaves an entry in the log with the result “refused” and the description “Viewing a development session refused”.
- The “notice” severity — the access operation. This is above “info”, which marks routine actions, and below “warning”: other people’s sessions are viewed for a reason, but the security officer should see who does it and how often.
The entry has who (the owner’s login), the object — the session identifier, and in the details — the login of the developer whose session it is, and the project; as with all events — the address and browser.
How to find it in the log
In the audit log viewing and export events are in the “Development sessions” category — a separate button in the category filter. Device sign-in and revocation are in the “Sessions and sign-in” category, questions about sessions — in “Ask”, knowledge from Buff Code — in “Knowledge base”. Searching by a developer’s login finds the entries about their sessions: the login is in the description and in the details.
This is how a view entry looks in the JSON Lines export (the values
are illustrative; the summary text is stored in Russian):
{"id":418,"at":"2026-09-24T11:03:17.204915+00:00","org":"buff-demo","project":null,
"actor_kind":"user","actor":"demo-lead","session":"c2a5…","gid":"9821…","ip":"147.45.197.19",
"user_agent":"Mozilla/5.0 …","action":"ide.session_view","operation":"access","severity":"notice",
"target_kind":"dev_session","target":"ses_7f3a…","summary":"Просмотрена сессия разработки alice",
"detail":{"op":"dev_session_feed","login":"alice","project":"shop-web"},"ok":true,"error":null,
"prev_hash":"e5ac…","hash":"81df…"}An export has "action":"ide.session_export" and the description “Development session exported (alice)”.
What is deliberately not recorded
- Requesting a sign-in code and waiting for confirmation — the console asks and waits; what counts as an event is the person’s decision.
- Model calls — that is usage, and it is recorded where it is charged: in the developer’s session and in billing.
- Reading the knowledge base and the project’s repositories from Buff Code — reading, just as in the workspace.
- The list of your own sessions and viewing your own session — reading what is yours.
- Connection tool calls — the connector’s call log keeps them, with the developer’s name.
- Request and answer bodies, knowledge, credentials, sign-in codes, tokens and the device key — never.
Who needs it
The permission to read the audit log is granted separately — for example, to an information security officer. They see who allowed sign-ins on devices, who looked at other people’s sessions and what they exported — with export to CSV or JSON Lines and a hash chain, as described in Exporting the log.
Export
Exporting a development session: Markdown for reading and JSON with all messages; what the file contains, an example, what is left out, how it is audited.
If something does not work
Buff Code, workspace and connector messages during installation, sign-in, context choice, model and tool calls: what they mean and what to do.