What this manual is

This is the Cockpit Flight Deck Manual. It works like the owner's manual of a car: you do not read it front to back once and shelve it. You keep it open while you do a job, find the page for that job, follow the steps, and check the result against the lines that say what you should see.

Cockpit is a chat for people who build on Salesforce and MuleSoft. You describe what you want, the Copilot reads the systems you have connected, answers in plain words, and proposes changes that you approve one by one. Muse for Mule.

The manual is written for one reader in particular: an enterprise architect who leads a small team of developers and who will first try Cockpit on free, throwaway accounts before anything real is connected. If that is you, read chapters 1 to 4 in order, then use the rest as a reference.

The words this manual uses

How the manual is laid out

Each chapter is a tab. On a screen, the tabs run along the top; in the printed booklet each chapter starts on a new page. The booklet is the same text as the pages, in order, at the print view.

Reading conventions

• Numbered steps are things you do, in order. A line that begins "You should see" says what the screen shows when the step worked. If you do not see it, stop and look at chapter 10 before going on.
• Checklists have boxes. Tick them on paper, or copy them into your own notes.
• Example prompts are shown in a box labelled "Ask the Copilot". Type or paste them into the chat as they are, then change the names to your own.
• Figures marked "Screenshot" are placeholders for real captures from the test drive. The list of what to capture is at the end of the manual.
• Illustrations are small drawings reproduced from how the product is built. They are labelled "Illustration" and are not screenshots.

The route in one page

The setup runbook that this manual grew from estimated about three hours in one sitting for chapters 3 and 6 together. Treat that as an estimate: vendor sign-ups wait on emails and trial activation.

Three rules that keep you safe

• Secrets go in the password manager, never in chat, email or a document. That includes passwords, Consumer Secrets, client secrets and API keys.
• When a screen says a key is shown once, keep that page open until you have pasted the key where the step says. If you close it, create a new key.
• Do every first test in Sandbox. In Sandbox nothing can be changed, even by mistake.

Status of this edition

This edition describes the product as it is built today. Where something is designed but not shipped, the text says arriving. Where the owner has not yet confirmed a statement, it says to be confirmed.

Vendor screens (Salesforce, MuleSoft, GitHub, Postman, Slack, Google) change often. The vendor steps in chapters 3 and 6 were written from the setup runbook and the vendors' documented flows. Where a vendor screen looks different, follow its prompts and keep to the intent of the step.

What Cockpit is

Cockpit is a chat-first console. You describe an outcome in plain words. The Copilot decides which of your connected systems to read, reads them with a fixed set of tools, and answers with what it found. When a change is needed, it proposes the change as an approval card and waits for you.

You can connect five systems: Salesforce (one or more orgs), MuleSoft (Anypoint Platform), GitHub, Slack and Postman. Your Google sign-in is listed alongside them on the Connectors page. Cockpit runs in a web browser, and as an app for Mac and Windows. Phone apps are coming.

Sandbox and Production

Cockpit has two modes. They describe what Cockpit may do, not what kind of org you connected. A free Developer Edition org can be used in Production mode; a real production org can be used in Sandbox.

There are three ways to be more careful than the account mode:

• Per connector. In Production mode you can turn writes off for one connector at a time (for example, Slack read-only while Salesforce can write). The switches are in the panel under the chip and on the Modes page.
• Per chat. A single chat can be made Sandbox from its menu in the Chats panel. That chat stays Sandbox for good: it cannot be switched back, and you start a new chat to write again.
• By attaching an org. Attaching a Salesforce org to a chat with the plus button (arriving) makes that chat Sandbox for the same reason.

The strictest setting always wins. The account mode, the chat's mode and what is switched on in the Cockpit deployment are combined, and the result is enforced on the server before any tool is offered to the Copilot. The chip is a view of that setting; it is not what protects you.

Approval cards

Every write waits for an approval card. The card is built from the exact call that will run, not from a summary the AI wrote about it.

{
  "sobject": "Account",
  "fields": { "Name": "Example Ltd" }
}

• Summary. One plain sentence, for example "Create a Account in Salesforce with Name".
• Exactly what will run. The complete input, in a box you can scroll. If a change is too large to show in full, it is split into several cards instead of being cut short.
• A SHA-256 fingerprint of that input. The approval is bound to it: if the input changed, the approval would not apply.
• Where it lands. The card names the Salesforce org (name and address), the Slack workspace, or the GitHub repository and base branch. The approval is bound to that target too. Before the write runs, Cockpit reads the target again. If you moved the chat to another org, reconnected the org to a different address, or the repository's default branch changed, the write is not sent and the answer says why.
• Tool name and blast radius. The name of the tool, and a short statement of how far the change reaches.
• Approve or Deny. Denying writes nothing.

• A card expires after 10 minutes. A late decision is refused and the card shows expired.
• If you tighten the mode after a card appears, approving it is refused and nothing is changed.
• "Always allow" exists only for plans and reads. It is never offered for a write, so every write needs its own approval.
• Your approvals are listed on the Approvals page and under the Approvals tab of the Brain panel.

What the Copilot can and cannot do

Which of these write actions your account actually has depends on what is switched on in the Cockpit deployment you use. They are being switched on in stages: GitHub pull requests first, then Salesforce records, then Slack posts. The Connectors page tells you for each connector: the tag reads "Read + write" when writes are possible and "Read only (no write actions yet)" when the connector has none switched on.

What is stored

• Deleting a chat removes it from your list at once and for good after 30 days.
• Disconnect stops Cockpit using a connection. Its chats are kept, but they cannot read that system again until you reconnect it. What else Disconnect removes depends on the connector, and the confirmation sentence says which: on GitHub and Slack it keeps the app details you saved so you can reconnect in one click; on a MuleSoft connection it removes the saved client id and secret; on Postman it deletes the stored key, and the key still works in Postman until you revoke it there.
• Delete, on a connector card, removes the connection and your saved app key and secret as well.
• Delete account on the Account page removes your account and everything in it straight away: threads, approvals, connections, usage, devices and AI consent. Cockpit asks each connected tool to revoke its access where the tool allows it. MuleSoft and Postman keys cannot be revoked by Cockpit; it deletes its copy, and you revoke them in Anypoint and Postman. Encrypted backups expire on their normal cycle.

Where your data goes: one AI provider

Cockpit uses one AI provider, Anthropic (Claude). To answer you, Cockpit sends your messages, and the results of the tools the Copilot uses for you, to Anthropic. It does that to produce replies. Before your first chat the console asks you to agree to this, and you can withdraw your agreement at any time on the Account page; chat stops until you agree again. The provider list has a version: if it ever changes, you are asked again.

Your connected systems are contacted by Cockpit's servers, using the credentials in the vault, when the Copilot calls a tool. The AI provider does not log in to your systems; it receives only what Cockpit sends it.

The privacy policy, in its current published form, is at cockpitai.io/privacy. Where this manual and the policy differ, the policy governs.

Why test accounts first

Before Cockpit sees anything of yours, it sees accounts that you made an hour ago and can throw away. You learn what it reads, what it asks permission for and what an approval card looks like, with nothing to lose. This is the test-drive rule.

The setup takes about three hours in one sitting if nothing waits on an email. You need a phone for verification codes and a browser in which you are signed in only as yourself. A fresh browser profile is best.

Your accounts sheet

Fill this in as you go. It is the one page you need if you ever have to redo a step. Do not write passwords on it.

3.1 A public Gmail

This one address does three jobs: it is the email you sign in to Cockpit with, it receives every vendor's verification mail, and, through plus-addressing, it can stand in for several addresses. Mail sent to yourname+sf2@gmail.com arrives in the inbox of yourname@gmail.com.

3.2 A password manager

1Password, Bitwarden or Apple Passwords all do the job. Every account below gets a strong, unique password saved here, and so does every Consumer Secret, client secret and API key you meet in chapter 6.

3.3 Two Salesforce Developer Edition orgs

A Developer Edition org is a free, private copy of Salesforce with sample data, made for learning. An org is one such copy. You make two: the first for the main test, the second to prove Cockpit handles more than one. Allow about ten minutes each.

3.4 Two MuleSoft trial accounts

MuleSoft Anypoint Platform is where companies build and run the connections between their systems. You make two free trial accounts. Trials last a limited time, so plan to do the whole test drive within a week of creating them. Allow about ten minutes each.

The connected app that lets Cockpit read each Anypoint account is made in chapter 6, once Cockpit is open next to it.

3.5 GitHub

GitHub is where software teams keep their code. Cockpit reads code from it and, in Production mode, can propose a change as a pull request, which your team reviews before anything is merged. Allow about five minutes.

3.6 Postman

Postman is a tool for testing and documenting APIs. Postman does not let other apps sign in on your behalf, so Cockpit uses an API key that you create. A Postman key can do everything its owner can do, and Postman cannot limit it to read-only.

The API key is created in chapter 6, next to Cockpit's page for it.

3.7 Slack

Cockpit connects to Slack through your own Slack app, so for the test drive you make a free workspace of your own. You make the app itself in chapter 6, because it needs a web address that Cockpit shows you.

Pre-flight checklist

The route

Cockpit is in private beta. Nobody can use it until their email address has been approved, and approval is for the exact address you give. Use the test Gmail from chapter 3 throughout.

4.1 Request access

4.2 Wait for approval

On the Cockpit side, an administrator reads the request in an Admin page that only administrators see, and approves or declines the exact email address. Approving sends you an email with the subject You are in: welcome to Cockpit. It says to sign in with Google, and that your 7-day Pro trial starts when you first sign in.

If you sign in before you are approved, Cockpit does not let you in. It shows a waiting screen:

• A pill reading Waiting for approval.
• The sentence "Cockpit is in private beta, so request access and we will email you as soon as you are in."
• "You are signed in as ..." with your address.
• Three steps: ask for access with the button; requests are reviewed and you are emailed, usually within a day or two; once approved, reopen Cockpit and sign in with the same Google account.
• A Request access button, and the support address support@cockpitai.io.

4.3 Sign in

4.4 Your 7-day trial

The trial starts the first time you sign in, not when you request access or when you are approved. No card is asked for. A bar at the top of the console counts it down.

• During the trial: "Pro trial: N days left. No card needed."
• After it: "Your 7-day Pro trial has ended. You can still read everything." Cockpit becomes read-only: you can read everything, but you cannot start chats, decide approvals or change connections. The bar offers Join the waitlist for paid; online payment is not available.
• An administrator can extend or end a trial.

4.5 Agreeing to the AI provider

Before your first chat, Cockpit asks you once to agree to your messages, and the results of the tools the Copilot uses for you, being sent to its AI provider. The dialog is titled Before your first chat. It names the provider, Anthropic (Claude), and what it does with the data: it answers every chat message and writes the code and configuration your chats ask for.

• Agree records your agreement and sends the message you were writing.
• Not now closes the dialog. Chat stays off; the message box shows "Chat is off until you agree to Cockpit sending your messages to its AI providers." with a Review and agree link.
• You can withdraw at any time under AI processing on the Account page. Chat stops until you agree again, and your chats stay.

4.6 Your first screen

After you sign in the console opens on the chat. This is what is on it. Chapter 5 describes every control in turn.

Boarding checklist

5.1 The rail

The rail runs down the left edge and stays in view on every page. On a phone (480 px wide or narrower) it becomes a bar along the bottom. Each icon has its name as a tooltip and as its accessible label.

The Connectors, Approvals, Modes and Account pages also show a settings list at their left (a row of links on a narrow screen). Modes is reached from that list, from the Account page, or from the chip's panel. In a team, a Team entry is in that list too (chapter 9).

5.2 The chat

The chat is where you work. From top to bottom, left to right:

Under the box, one line repeats the safety promise: "Every write the Copilot proposes waits for your approval. Nothing ships without you."

A banner at the top of a chat says when Sandbox is on: "Sandbox is on: Cockpit can read your connected systems but nothing can be changed. If you ask for a change, it will say so and change nothing." If only that chat has been made Sandbox, the banner says that chat stays Sandbox.

While the Copilot works, you see its steps stream into the chat. If your connection drops during a run, the console reconnects to the run by itself with growing pauses, so a deploy or a network blip does not lose the answer.

5.3 The Chats panel and the Brain panel

• New thread starts a chat. Search chats finds earlier ones by their words.
• Each chat has an Options menu with Rename, Delete, and Make this chat sandbox. After you use the last, the menu reads "This chat is Sandbox" and the chat carries a green Sandbox tag. A chat can only be tightened this way, never loosened.
• An amber dot beside a chat means it is waiting for your approval.
• Delete asks first. The chat leaves your list at once and is removed for good after 30 days.

Under 900 px wide, the Chats and Brain panels open as drawers over the conversation. Escape closes a drawer.

The Brain panel says who is working and what it did. It has four tabs:

The panel also shows API usage for your Salesforce org ("No Salesforce API calls in this thread yet" until one is made) and a Safety badge: "Read-only" with "Sandbox is on: nothing can be changed.", or "Read + write" with "Production mode (read + write): every change asks for your approval first."

5.4 The mode chip, the mode panel and the Modes page

Click the chip to open the mode panel. It has a master switch and a row for each connector.

• Production mode (read + write) is the master switch. Turning it on asks you to confirm: "Switch to Production mode (read + write)?" The confirmation says Cockpit will be able to make changes where a write action exists, that every change still asks for your approval, that the mode does not describe what kind of org is connected, and that you can switch back to Sandbox at any time with no confirmation. The buttons are Switch to Production mode and Stay in Sandbox.
• Per connector rows (Salesforce, MuleSoft, Slack, GitHub, Postman, Workstation) show, in Sandbox, "read only in Sandbox". In Production mode, each shows "can write, each write asks for approval" with a switch you can turn off, which changes it to "read only (you switched writes off)". A connector with no write action shows "read only (no write actions yet)" and its switch is locked.
• The Modes page has the same switches, a note that a new chat follows the account mode, a count of requests held back by a mode in the last 30 days ("These are not errors: nothing was changed."), and a list of recent mode changes with times.

5.5 Connectors

Open Connectors from the rail. The page explains that you have one connection per platform, except Salesforce and MuleSoft, where you can connect several and pick one for each chat. Google is how you signed in.

• A Search box filters by name.
• Two tabs, Connected and Available, with counts. The page opens on Available until something is connected.
• The Salesforce and MuleSoft cards sit above the tabs, because each can hold several connections.
• Each other connector is a row. Click its name to open its detail: Identity (who the connection is), Health (status, last test, connected since, last used, token expiry, last error) and App (which app, the saved key and whether a secret is saved, and the scopes, summarised as "N permissions (show all)").
• A row shows connected or not connected, its capability tag, and a Connect button when it is not connected.
• A connected row has Test, Reconnect, Disconnect and, for connectors you connect with your own app or key, Delete. Test makes one real read-only call and reports "Test passed" or "Test failed" with a reason. Each of Disconnect and Delete asks you to confirm.

The Salesforce card lists every org you connected, each with its name, org-type chip, a health label (Working, Needs reconnect, or Not checked yet), when it was connected and last used, and buttons:

• Add Salesforce org opens the four-step guide of chapter 6. Setup guide opens the same guide.
• Rename gives an org a name you recognise (up to 120 characters).
• Reconnect replaces that org's sign-in. Disconnect keeps the org's chats but they cannot read it until you reconnect.
• Run discovery report (where switched on) reads the org once and writes the Org Discovery Report into a chat. Hovering it says "Reads this org and writes a report. It changes nothing in Salesforce." The finished report can be downloaded as Markdown (.md) or as its tables in CSV.

The MuleSoft card works the same way, with Add MuleSoft connector, and shows the region and organisation of each connection. A red notice at the top of a card with "Needs reconnect" means the provider refused the saved sign-in.

5.6 Approvals

The Approvals page lists every approval card waiting across all your chats, grouped by chat, newest first, with a Refresh button. It says: "Every write the Copilot proposes waits here. Nothing ships without you." When nothing is pending it shows "All clear" and "No pending approvals." with a link back to the console.

Each card has the layout shown in chapter 2: summary, exactly what will run, fingerprint, tags and the target. Approve and Deny decide it. A decided card shows who decided and when. After your trial has ended, both buttons are disabled and a line says so.

5.7 Account

5.8 The microphone

The microphone beside the send button dictates into the message box, using your browser's or phone's own speech recognition. Cockpit's servers do not do the speech recognition. The button is hidden where the browser has none.

5.9 The attach menu (arriving)

• Plus opens a small menu: Salesforce org (with a count such as "2 connected"), or Connect something new.... With no org connected, the first entry reads Connect a Salesforce org.
• Choosing Salesforce org opens a sheet, Attach a Salesforce org: pick the org, give it a short name (lower-case letters, digits and dashes, up to 24 characters, starting with a letter or digit; suggestions are dev, qa and uat for a sandbox and prod for Production), and press Attach.
• The sheet shows Access as Read only; "Read and write" is greyed out with the note "Writing through an attached org comes later. For now it is read only."
• A chat can have up to 4 orgs attached. They appear as chips such as "dev · Salesforce · read only", each with a Detach button, and you can then ask the Copilot to compare them by name.

5.10 The desktop apps

Cockpit for Mac and Cockpit for Windows are the same console in a window of its own. They are beta downloads. The download buttons appear for approved accounts only, on the Account page and in the chat's top bar, and not inside the apps.

The card for your own system comes first with the main button; the other follows as a second choice.

The menu bar also has the usual Edit, View and Window menus, and a Help menu with Cockpit Manual (opens this manual in the app), Check for Updates and Copy Diagnostics. The zoom, reload and close keys are the ones every app uses. Check for Updates tells you only when a newer version exists; it never installs anything. Where update checks are not switched on, it opens the Cockpit website instead.

A line reads "unknown" when it could not be found, for example the service versions when you are offline.

If the page itself stops working, the app reloads it, up to three times in a minute, and then leaves you on that screen. The app also remembers its window size and place, and reopens in them; if a screen has been unplugged it opens on one that is there. The window cannot be made smaller than 900 by 600.

5.11 Phones

Controls checklist

Before you connect anything

Do this chapter in two passes. Pass one connects the throwaway accounts from chapter 3. Pass two, only after the test drive, covers what changes when the systems are real; it is at the end of the chapter.

6.1 Salesforce

Salesforce only lets an outside program in through an app that you create and control. Salesforce calls it an External Client App. You make one per org, copy its Consumer Key (and Secret) into Cockpit, and Cockpit sends you to Salesforce to sign in and approve. You decide the permissions. Do this once for org 1, then once for org 2; allow about ten minutes each.

Prove it: start a chat, pick the org, and ask the first prompt in chapter 7 ("How close is this org to its API limits?"). A real number means the connection works.

6.2 MuleSoft

Cockpit reads your Anypoint organisation through a connected app that you create and that acts on its own behalf (client credentials). Cockpit only reads from Anypoint, so the app gets read-only scopes. Do this once for each trial account.

Repeat for the second trial. Cockpit lets you pick which Anypoint organisation each chat uses. If Test fails with 401 or 403, the region, the app type or the scopes are wrong: recreate the app as client credentials with the four scopes.

6.3 GitHub

GitHub connects through Cockpit's own GitHub sign-in, so you create nothing. It asks for GitHub's standard repo access (and read:user). GitHub offers no read-only version of repo for private repositories, so GitHub describes it as read and write. What keeps Cockpit to reading is its mode, not the sign-in.

6.4 Slack

Slack connects through your own Slack app in your workspace, so you control the permissions. Cockpit connects as you (a user token), so it can read what you can see and search it. It reads channels only; direct messages are a separate, optional consent that you can decline. Allow about fifteen minutes.

6.5 Postman

6.6 Check everything

6.7 Pass two: real systems

When the test drive has shown you what Cockpit reads and asks for, you can connect real systems. The procedures are the same. What changes is who is affected and what you should decide first.

How to judge any answer

The Copilot works from built-in guides (we call them recipes). Each one fixes the steps, the questions it may ask your system, and the shape of the answer. You do not name a recipe: you describe the job, and the Copilot uses the one that fits. Every recipe in this chapter is read-only: it reads and explains, and never offers to change anything.

7.1 The first question

Before the guides, prove the connection returns real data.

A good answer reports real numbers from the org's limits and says which are nearly used. In a new org, nothing will be close. The API meter above the message box then shows your calls this run.

Then one question per connected system. Note each result on your checklist:

7.2 Explain a debug log

Needs: nothing connected. It reads only what you paste. It touches no system.

To try it without a real log, paste these made-up lines:

• A good answer, in this order: one plain sentence with the cause; a table of limit, used and allowed (only limits in your paste; any at 80 percent or more flagged); the top three suspects, each with a log line number or a class and line; the usual fix. It says which part is your paste and which part is its reasoning.
• For a SOQL limit, the usual cause is a query inside a loop, and the usual fix is to query once into a Map.
• If the error is not one it recognises, it says "not recognised", says what it can read, and asks for the missing part.

Check: every suspect cites a line you can see in your paste. It does not name a class the paste does not show. It does not offer to fetch the log itself.

7.3 Org tour

Needs: a connected Salesforce org. A guided walk through an org you have just inherited, in about ten minutes of reading.

• A good answer goes in seven steps and stops after each with one line asking whether to go on: org summary and licences; data model; automation; integration surface (installed packages, named credentials); limits; security risks; and what changed in the last 30 days. It uses the same sections as the Org Discovery Report (7.10).
• Each step is two or three plain sentences, a small table if it helps, and what it means for someone taking over.
• It ends with Five things to read first and Three things that look risky, naming only things it read. On a small org it gives fewer and says the tour cannot show business rules that are not written down.
• A part it cannot read is listed as "not readable with your access" in its step and again at the end.

Check: pick one named object or flow and find it in Setup. It should be there. It should not call anything a bug.

7.4 Async job doctor

Needs: a connected Salesforce org. Finds background work that has quietly failed.

• A good answer starts with one sentence (for example "3 classes failed in the last 7 days and 1 schedule looks stuck", or "nothing failed in the last 7 days"), then a table of job, failures, last error and last success, then any stuck schedules. A schedule is flagged when it should have run and did not, or is in an error or blocked state.
• It counts what it can see and says so. It always lists what it did not check: failed Flow interviews, fault emails, platform event delivery and email send errors, which need Event Monitoring or admin settings. It never says the org is healthy about those.
• It never offers to abort, reschedule, retry or change a job.

Check: in Setup, open Apex Jobs and compare the failures it names. A new Developer org will normally answer "nothing failed", which is correct.

7.5 Licence, storage and idle-user review

Needs: a connected Salesforce org.

• A good answer gives a table of licence, used, total and free, largest free first (rows with a total of 0 left out); idle users who have not logged in for 90 days, oldest first, up to 20, with the total, and users who never logged in; and storage as used = Max minus Remaining, with the percent used, from the org's limits.
• It calls idle users "candidates to ask about", because they may be integration or seasonal users. It does not tell you to remove anyone.
• For storage per object it can only count records on a few objects and says its space figure is an estimate (Salesforce counts most records as about 2 KB).
• It does not state or guess what a licence or a gigabyte costs, unless you give it a price.

Check: compare the licence table with Setup, Company Information. Compare the storage figures with Setup, Storage Usage.

7.6 Who can edit a field

Needs: a connected Salesforce org and a user in it. In a new Developer org, use your own admin user or a user you create.

• A good answer gives the deciding reason first in one line, then the chain: who the user is (profile, role, active or not), each profile, permission set or permission set group that grants something, and what is missing if the answer is no. Editing a field needs Edit on the object and Edit on the field.
• If more than one user matches the name, it lists them and asks which. If the user is inactive, it says so and stops.
• For a grant that arrives through a permission set group, it says "granted through the group X unless the group mutes it", because muting is not evaluated.
• It always says "Record-level sharing was not evaluated". Object and field access say whether the user can edit the field at all, not which records they can see.

Check: open the user in Setup, then the permission sets and the field's field-level security, and confirm the chain.

7.7 Sandbox refresh checklist

Needs: a connected Salesforce sandbox. It lists what to note before a sandbox refresh and checks what is left after it. A person does the refresh in Setup; the Copilot cannot start or schedule one.

• Before: one table per area (named credentials, external data sources, remote site settings, outbound messages, scheduled jobs, connected apps, custom settings) with what, name, the value to note and what to do. Then a manual list of things the API cannot give, each with where to look in Setup. Anything it could not read is on the manual list, not guessed.
• After: the same reads again. It asks which production hosts your integrations point at, then flags any endpoint whose host equals a production host as pointing at production, and lists same-domain hosts as "check". If you decline to name hosts, it lists every host and says nothing was compared.
• Nothing is stored beyond the chat: copy the "before" table somewhere safe, and paste it back in the "after" chat.

Check: the "after" run flags nothing for an integration you know still points at its sandbox endpoint.

7.8 Pull request review

Needs: GitHub connected, and a pull request in a repository the connected user can see. It reviews the Apex and Flow files of one pull request against a fixed checklist of ten rules.

• A good answer lists findings, high severity first. Each has the rule (R1 to R10), the severity, the repository, the file path, the short head sha, the line range, the line quoted exactly, why it matters in one sentence and the fix. For the class above, expect R1 (a query inside a loop) and R2 (a data change inside a loop), and probably R5 (no sharing keyword).
• It reviews only Apex, trigger and Flow files and names the other changed files as not reviewed. It says how many pages of files it did not read.
• No findings is a valid answer: "No findings from the ten rules in the files I read", with the files listed.
• It never posts a comment, approves, or requests changes, and never calls the pull request safe: it read a diff, it did not run it.

Check: open the file at the sha it names and compare the quoted line and its number. If the line number matters and it was unsure, it should have confirmed with a file read before citing it.

7.9 Pull request description and release notes

Needs: GitHub connected. It writes text in the chat for you to paste. It cannot put it into the pull request.

• A good answer uses the repository's pull request template if it has one, keeping its headings in order, and leaves every checkbox unticked with "to be ticked by the author". Without a template: Summary, Components changed (each changed file in exactly one section, such as Apex classes, Flows or Tests), Risk (low, medium or high, with the reason, stated as its judgement), Test plan and Deploy notes.
• It never says a test ran or passed unless a tool result says so. It names a ticket only if the key is in the title, description or a commit message.
• Deploy notes contain only what the file types support. A file named destructiveChanges removes components and is called out first.
• It says in one line what the text cannot know: it describes the diff and messages, not what was run or what is in the org.

Check: count the changed files on GitHub against the files listed in the answer. The guide tells the Copilot to make them match.

7.10 The Org Discovery Report

Needs: a connected Salesforce org, and the report switched on for your environment. It reads the org once, within a fixed call limit, and writes a report into a chat. It changes nothing in Salesforce.

• The report states its date. A part the connected user cannot read is marked not readable with your access; a part skipped because the report reached its call limit, or to protect your API allowance, says so.
• Afterwards, ask follow-up questions in the same chat. The Copilot quotes the report's numbers and does not recompute them. For anything newer, it uses its tools and says the report may be out of date.

Check: compare the date and two numbers (for example the count of custom objects) with Setup.

7.11 More guides

These work the same way: read-only, honest about what they could not read, and never offering to change anything. Try them after the nine above.

When to use Production mode

"Production" here is the name of a Cockpit mode, not a statement about the org. A free Developer Edition org can be used in Production mode, and a real production org can be used in Sandbox. The risk is set by what is connected, not by the mode's name.

• Stay in Sandbox for everything in chapter 7.
• Switch to Production mode only for a specific write you mean to make, and switch back afterwards.
• New accounts start in Sandbox, and every write needs a card.

How a write works

These are switched on in stages (GitHub pull requests, then Salesforce records, then Slack posts). If you ask for a write whose action is not on yet, the Copilot says it has no write action for that, and nothing is changed. The tag on the Connectors card ("Read only (no write actions yet)") tells you in advance.

• Sent once. A write has a 30-second limit and is never retried.
• Refused means unchanged. If the system refuses (an HTTP 4xx), the answer says "... refused the change (HTTP 4xx), so nothing was changed." with the system's reason.
• Not confirmed means check. If the connection drops, times out, or the system errors (5xx), the answer says the system "did not confirm the change ... so the record may or may not have been applied. Cockpit did not try again. Tell the user to check ... before asking for it again." Do exactly that: look in the system before you ask again.
• The target is checked twice. It is named on the card, and read again when you approve. If it moved, the write is not sent: "approved for X, but it would now go to Y. Nothing was changed."
• A tightened mode cancels it. Switching to Sandbox, or switching that connector's writes off, after a card appears makes approving refuse with "Mode changed, nothing was changed."
• Where a write cannot start, no card appears and the answer says why, for example when the org is not connected, GitHub is not connected, your GitHub login cannot push to that repository, or the repository is archived.

Switching Production mode on and off

Before you approve: the checklist

Run through this on every card. It takes under a minute, and the card is built so that every answer is on it.

Three first writes on the test accounts

Do these in your throwaway orgs, one at a time, with the checklist above. Each one is small, and each is something you can undo by hand.

Also try Deny once, on any card. Check that nothing was written.

Afterwards

• Check the result in the system, not only in the chat.
• The Modes page lists your recent mode changes, and the count of requests held back by a mode in the last 30 days.
• The Approvals tab of the Brain panel and the chat itself keep each decided card, with who decided and when.
• Switch back to Sandbox.

Status: only for teams, switched on per customer

Without a team, every person has an individual account: their own sign-in with Google, their own connections, chats, modes and approvals. With a team, each person still has their own connections, chats, modes and approvals. What the team adds is one place where a Captain decides who is in and which connectors each person may use.

Captain and Crew

A person belongs to one team at most. There is no directory or single sign-on in the first version.

How a team starts

Team members sign in with an email address and password, on a separate door of the sign-in page, not with Google. Members do not have a 7-day trial clock. The desktop apps hand sign-in to the browser, as they do now (9.3).

9.1 The Captain's team page

A Captain opens Team from the settings list (the same list as Connectors and Account) or goes to /app/team. The page is called Your team members. At the top it says which team you are a Captain of. Below it are the invite form and the list of people.

Two other lines can appear instead. "... already has a sign-in. They can sign in at the team door and the invitation is accepted." means that address already has a Cockpit sign-in, so no email was needed. "... is added, but the invitation could not be sent just now. Use Send again in a moment." means the sign-in service could not be reached; the person is on the list, and Send again tries once more.

Each active person's line also says what they have connected (for example "Connected: Salesforce (dev)"), or "Nothing connected yet.", and what they have spent on the Copilot this month against their budget. It does not show their chats.

9.2 What a team member sees

A team member who opens Team sees a page with no controls. It says "You are part of <team>.", names the Captain ("Your Captain is <name> (<address>)."), and lists What you can use: each connector as Not enabled, Read only or Read and write. Under it: "Ask your Captain if you need another connector." A person who is not in a team who opens /app/team is told "You are not part of a team."

On the Connectors page, a connector set to Not enabled shows as not enabled by the Captain, with no Connect button.

9.3 The team door: Sign in to a team

A new member's first visit is the link in the invitation email. That page says "Choose a password to join your team." After that, use the team door each time.

9.4 What the Captain controls

For each member and each connector (Salesforce, MuleSoft, Slack, GitHub, Postman, and the Workstation, which is not available today) the Captain sets a level:

Presets save time: Everything (read and write), Salesforce only, Salesforce and MuleSoft, or Nothing yet when you invite, and any combination of connectors afterwards (9.1).

9.5 What the Captain sees, and does not

Connections, chats, the Workstation and the AI budget are per member. Nothing is shared in the first version. A write that a member approves is attributable twice: to their approval in Cockpit, and to their own login in the customer's system.

9.6 Removing a person

• Removal cuts the person off at once: their access, runner tokens, connections (revoked where the provider allows) and running tasks.
• Their data is kept invisible for a 30-day grace period and then purged, or purged at once if the Captain chooses.
• A person can always delete their own account, whether Crew or Captain. If the last Captain deletes their account, the team is suspended and the Cockpit owner is told.

9.7 Planning for a team of six

Pricing for teams is by quotation: ask support@cockpitai.io. Online payment is not available.

Start here

Most problems are a copied value with a stray space, or a step done in the wrong order. Find the message, or the symptom, below.

Sign-in and access

Connecting

After a connect attempt, the Connectors page shows one line saying what happened. These are those lines, and the messages from the vendors that often cause them.

On a card, Needs reconnect means the provider refused the saved sign-in or key. Press Reconnect. Not checked yet means Test has not been pressed. Test failed shows the vendor's reason.

Chat and answers

Modes and approvals

Sandbox, Production and your approval cards

Two different things are called Sandbox and Production, and a card can show both. The mode (Sandbox or Production, the chip at the top) decides whether a card can appear at all. The target on the card names the system the change will land in, and for MuleSoft it also says what kind of environment that is.

Limits in one run

Each kind of write can be asked for only a few times in one chat run, so a loop cannot fill your screen with cards. The Copilot tells you in the chat in the limit's own words, for example "exchange_publish: at most 6 calls in one chat run (a limit set for this environment)."

In Sandbox mode a write is turned away before it is counted, so a refused write does not use up a limit.

Writes

Microphone and apps

If nothing here helps

Terms

Two words are easy to confuse. Sandbox mode and Production mode are modes of Cockpit. A Salesforce sandbox and a Salesforce production org are kinds of org. A Developer Edition org can be used in Production mode, and a production org can be used in Sandbox mode.

The card

What the Workbench is

The Workbench is a page next to the chat for the jobs a developer does with a mouse and a keyboard: write a SOQL query and read the rows, look up what fields an object has, and check what is deployed in MuleSoft. It is the same page in the browser, in the Mac app and in the Windows app.

It only reads. There is no button on it that creates, changes, deploys, stops or deletes anything. That is true in every mode and for every org, including Production. The Workbench panels do not use an AI model and never send anything to the Copilot on their own: rows, logs and cell values reach the Copilot only when you choose to send them, and you see exactly what goes first.

Open it from the rail (the window icon, labelled Workbench). At the top, choose the Salesforce org. Each org shows its type, and a Production org also shows a note that the page only reads there.

13.1 Run a query

Before the first run, the empty page offers example queries you can start from: the newest accounts, a count of contacts, open opportunities, and two that read setup data (Apex classes and validation rules). Picking one fills the box; it does not run until you press Run.

The query box colours keywords, text values, numbers and dates as you type. It is a plain text box: nothing is changed in your text, and a pasted query keeps its line breaks.

History and Saved. Beside the box, History keeps your last 50 queries (the text of the query, whether it worked, how many rows, and the org). Running the same query again refreshes its line instead of adding another. Click one to put it back in the box; it does not run until you press Run. Saved holds up to 100 queries you named. Both are yours alone, and both are removed when you delete your account. Neither ever holds the rows a query returned.

What it will not run. One SELECT at a time. A second statement after a semicolon, FOR UPDATE, and any query with a write word such as INSERT, UPDATE or DELETE are refused with a sentence saying why, before anything is sent to Salesforce.

13.2 Browse objects and fields

• Add puts the field in the SELECT list of a query that already reads that object. If your query reads another object, or the box is empty, it starts a new query on this object.
• A lookup field also shows a second button with the parent's name, for example Owner.Name, so you can bring the parent's value into the same row.
• In Relationships, Add subquery adds the children of the object, for example (SELECT Id FROM Contacts), to the field list.
• A picklist field shows how many values it has. Press the number to list them (inactive values are struck through) and Copy values to copy them, one per line. A very long picklist shows its first 200.
• Query this object starts a fresh query on the object you are looking at.

Each object you open costs one Salesforce API call, and it is kept while the page is open, so going back to it costs nothing more.

13.3 Read the org's setup data

The Metadata tab lists what has been built in the org, without writing a query. Pick a kind on the left: Apex classes, Apex triggers, flows, validation rules, custom objects, custom fields, Lightning web components, installed packages, record types, permission sets or profiles. The list appears in the same grid as a query result, so you can sort it, filter it, open a row as a list, copy it or download it as CSV.

• Each kind is a plain read-only query. The code and automation ones read through Salesforce's Tooling API, the same as the Setup data switch on the Query tab.
• Open in Query puts that query in the Query tab's box so you can change it, for example to add a WHERE clause.
• A list is kept while the page is open, so going back to a kind does not read it again. Refresh reads it again.
• Up to 2,000 rows are read for each kind. If an org has more, the page says the list was cut.

13.4 Watch the org's limits

The Limits tab reads the org's limits in one call and shows each as a gauge: how much is used, how much is left, and the share used. The ones closest to their maximum come first. A gauge is green below 70 percent, amber from 70, and red from 90. Limits the org gives no maximum for are left out. Use the search box to find one, for example API or storage, and Refresh to read them again.

13.5 MuleSoft deployments and APIs

The MuleSoft tab reads from Anypoint with the connected app you set up in chapter 6. Choose the connection and the environment. A production environment shows a note that the page only reads.

Above the tables, tiles show the organisation's name, its subscription and the vCores assigned to Production, Sandbox and Design. These are what Anypoint reports as assigned, not what is in use. A tile is left out when Anypoint does not report it.

• Deployments lists each application with its state: Failing, Starting, Running or Stopped. The ones that need a look come first, and a row of counts above the table gives the totals. Hover a state to see Anypoint's own status words. The table also shows the runtime version, the replicas and vCores, the artifact and when it last changed, where Anypoint reports them.
• APIs lists the API instances managed in the environment: the API and its instance name, version, status, active contracts and endpoint. Press Policies on a row to see the policies applied to that API, in order.

If a value is missing from a row, Anypoint did not report it for that application, and the Workbench leaves it blank instead of guessing.

13.6 What it reads, what it records, and the limits

13.7 When something goes wrong

If a message is not in this table, or the page shows a reference that starts with CKP, send it to support and say what you were doing.

13.8 Search, charts, logs and shortcuts

These additions read exactly as the rest of the Workbench does: every call is a read, only your own connected orgs and MuleSoft connections can be reached, and nothing you do here is sent to an AI model on its own (rows and logs reach the Copilot only when you choose to send them).

Search (SOSL). The Search tab finds a word across many objects at once. Write a search that starts with FIND and the words in curly braces, for example FIND {Acme} IN ALL FIELDS RETURNING Account(Id, Name), Contact(Id, Name, Email), and press Search (or Ctrl or Command and Enter). The rows from every object share one grid, and the first column, SObject, says which object each row belongs to. Sort, filter, copy and download CSV work as they do for a query. Your last searches appear in History beside the box; click one to put it back in the box. If you paste a FIND into the Query tab and press Run, the Workbench moves it to the Search tab for you.

Charts. When a query result has a column of numbers, a Table and Chart switch appears above it. A query with COUNT(), SUM() or AVG() and a GROUP BY is the usual case. Pick Bars or Line, and choose which column is the label and which is the number. Bars are sorted with the largest first, unless the labels are years or months, which keep the order of the query. A chart shows at most 40 bars or 200 points and says when it left some out. For a screen reader the chart has a one-sentence summary, and under it a list called The numbers behind the chart gives every value as a table.

Apex logs. The Logs tab lists the newest debug logs in the org (who, what, when, how big, how long). Press Open on one to read it as numbered lines. Use Show to keep only errors, warnings or other levels, and the search box to find a word; press More lines for the next page and Older logs for the next page of the list. Cockpit works out each line's level from its event name (for example EXCEPTION_THROWN is an error, USER_DEBUG uses the level written in the line), so it is a good way to find the errors, but it is not Salesforce's own logging setting. Cockpit only reads logs: it does not turn trace flags on or off, and it does not delete a log. If the list is empty, no trace flag is on in Setup.

MuleSoft details and logs. In the Deployments table, Details opens one application: Anypoint's status words, the state it wants, the runtime, the size, the artifact, when it last changed, the last version that worked, each replica with its state, and its public address. Logs opens its newest log lines (50, 100 or 200) for a period you choose, with a level list and a search box. Lines are written by the application, so they are shown as plain text and anything that looks like a secret is hidden. Anypoint keeps the log by version, so an application that has not started yet answers that it has no log yet.

Saved query folders. When you save a query, the optional Folder box files it under that name; the Saved list then shows the queries grouped by folder, folders A to Z. A folder is just the first part of the saved name, written Folder / Name, so you can also rename by saving again with a new name.

13.9 Links and Open in Workbench

Every Workbench view has an address. The address follows the tab and the org you are on, so a reload comes back to the same place, and Copy link to this view copies it (on the Query tab it includes the SELECT in the box). Opening a link puts the query in the box and picks the tab; it never runs anything, so you press Run yourself.

In a chat, the Brain panel lists each tool the Copilot used. A step that has a Workbench panel (a Salesforce or Tooling query, a describe, a MuleSoft deployment status or log read) carries an Open in Workbench link that opens the same read on the same org. The link holds only the query text and identifiers, never a row, a log line or a token.

The org you pick in the Workbench is remembered as the one you are working in, and the chat uses the same choice. A link that names an org, object or deployment you do not have opens nothing for it. The search box (Ctrl K) lists each Workbench view that is on for you, for example Workbench: Logs, and opens it.

13.10 The GitHub tab

The GitHub tab reads one repository at a time, with your own GitHub sign-in: Pull requests (the list, then one with its checks, reviews and the diff of every changed file), Actions (runs, the jobs of one, and the end of a failed job's log, or just its error lines), Issues, Files (browse folders and read a file) and Search (code, issues, pull requests and commits). Type the repository as owner/name, or pick one from your own list.

It only reads. Nothing on this tab changes GitHub and nothing is sent to the Copilot. Everything GitHub sends is shown as text: a title that looks like a web page or a formula is shown as the characters it is. Secret-looking values in logs and files are hidden and counted, the values in .env files are always hidden, and key, certificate and binary files are not shown. A link to GitHub appears only when it really is a github.com address.

Each read is limited in rows and size, and you can make 20 to 60 a minute depending on the kind (searches and files are the fewest). The audit trail records the repository and the kind of read, never the path, the search text or what was read.

13.14 What the Copilot knows about the panel you have open

When this is switched on, the Copilot is told, in the short list of facts it gets with every message, which Workbench panel you have open and which of your connections (or which GitHub repository) it is on, for example: the Query panel on your Dev org. That is only the name of the panel and its connection. The Copilot cannot see what the panel shows: not a row, a log line, a file name or a query. If it needs something from the panel it asks you, and you decide whether to send it with Send to Copilot (13.12), after reading exactly what would be sent.

The note is replaced each time you change panel or org, is forgotten when you leave the Workbench or hide the page, and is not told to the Copilot after 15 minutes. It belongs to you, not to one chat, so any of your chats (and a scheduled run) can be told it while it is fresh. Only the panels your team's Captain has given you are ever named.

13.15 Access, audit and MuleSoft operations

When this is switched on, the Workbench has an Access and audit tab for your Salesforce org and an Operations view inside the MuleSoft tab. Each view is one of the Copilot's own read tools with a form in front of it: the same checks, the same hidden secrets and the same limits, on your own connection. Nothing on these pages changes anything, and nothing you read is sent to the Copilot unless you say so in a chat.

A form is sent only when it is complete: the page names a missing field, and a number, date or name that does not look right, before anything is sent. A field that does not apply to your question is not shown and not sent. Environments, applications and APIs are picked from lists read from your own connection. The answer is always shown as text, as a table, a list or a set of facts, and a line above it says how many reads it took and how many secret-looking values were hidden. A view your account does not have yet says so.

Limits: each view allows a few reads a minute (10 to 30, and 60 in all across these views), so the page asks you to wait if you go faster. The audit event names the view and the kind of question, never a name, an id or a row.

13.13 The Workstation tab

The Workstation tab is a read-only window on your own Workstation. It shows the machine's state and hours, a live Activity trail of what happened to it (starting, ready, stopping, errors), its files (browse folders, read a text file), and the git status and recent commits of a folder. There is no terminal and no editor: nothing here types into a file or runs a command you typed.

The tab never wakes your Workstation for you. When it is asleep the files and the Run menu say so, and the Wake button (with the hours it will use) is the only way to start it. Secret-looking values in files and output are hidden and counted, the values in .env files are always hidden, and key and binary files are not shown.

The Run menu starts one governed command on the machine: build a Mule project, scan Salesforce code, run Lightning web component tests, or run Apex tests in your default Salesforce org (the one your chats use). These change nothing in an org or on GitHub; they write only inside the workspace. One runs at a time (20 an hour), each uses Workstation hours while it works, and the output appears when it finishes. To deploy, run Apex or change a file, ask the Copilot in a chat: the approval card does the write.

13.11 Apex and jobs

The Apex and jobs tab reads five things from the chosen org, each a read-only query: Apex code coverage (lines covered per class and trigger, lowest first, with the org-wide figure the way the deploy check counts it), Failing Apex tests and Recent Apex test results, Async Apex jobs (batch, queueable and future jobs, newest first) and Scheduled jobs. Each has an Open in Query tab button, so you can change the query.

Record by Id shows the fields of one record: choose the object, paste the 15 or 18 character Id and press Open record. Its related lists are buttons that open a query for the children of that record in the Query tab; nothing runs until you press Run. Everything the org sends back is shown as text.

Nothing on this tab runs tests, runs Apex or changes a record. To do any of those, ask the Copilot in a chat: it proposes the action and the approval card does the write, with the same guards as always.

13.12 Send to Copilot

The Workbench never sends anything to the Copilot by itself. When you want the Copilot to look at what you are looking at, press Send to Copilot above a table of rows. A window shows you the exact text that would be sent: the rows you see (after your filter, the first 25 rows and 8 columns), with secrets, email addresses, cloud resource names, instance ids and Salesforce record ids replaced by a marker such as [hidden:email], and a count of what was hidden.

Nothing is stored until you press Send to Copilot in that window. Then Cockpit starts a new chat, bound to the same org, whose first message is that text, and opens it. No AI model has been asked anything yet: the Copilot reads the excerpt when you ask your first question in that chat. Cancel, or Escape, sends nothing. The excerpt is marked as data, so text inside it is never treated as an instruction.

You can make 10 sends a minute. The audit trail records the panel, the number of rows, the size and the counts of what was hidden, never a cell or the title.

What the board is

The board is a page next to the chat that shows your work as cards in four columns. A card stands for a piece of real work, usually one chat. You do not have to keep it up to date: it moves by itself when something real happens in that chat (14.2). You can always move a card yourself.

Every card says which phase it belongs to and, when the board moved it, why (for example, "Waiting for your approval"), with the words "moved by itself". A card made from a chat also carries small links: one back to the chat, and one to each approval card or pull request that came out of it. Above the columns a line says how many cards are waiting on you.

14.1 Start and use a board

14.2 How cards move by themselves

A card in a chat moves only because of something that really happened, and the card says what. Nothing moves because of a guess.

Two things are added to the card without moving it: a link to the approval card, and a link marked "A pull request was opened" when the Copilot opened one for you. A rule only applies to a card in the right column. A card you left in Done is not moved by an approval, for example.

14.3 Phases and the gate

A project has three phases, shown as three boxes above the columns. Discovery is finding out what is there and what is in the way. Design is deciding what to build. Develop is building and shipping it. The box for the phase you are in says "now", finished ones say "approved", and later ones say "not yet". A project starts in discovery.

• That button is the gate. It is your go-ahead and it is recorded. Nothing else moves a phase: not the Copilot, and not a finished run.
• Phases go in order: discovery, then design, then develop. You cannot skip one or open one twice. There is no gate button once a project is in develop.
• A card you add has the phase the project is in now.

14.4 Move a card by keyboard, menu or mouse

After each move a screen reader says, for example, "Moved Fix the nightly job to Done." If the move did not reach Cockpit, the page shows the reason and puts the card back.

Board checklist

Appendix A: connector scopes

A scope is one specific permission you give to an app. These are what Cockpit asks for or tells you to add, taken from the product. Most providers have no read-only scope for what Cockpit reads, so it is Cockpit's Sandbox mode, enforced on the server, that keeps it to reading.

Appendix B: keyboard and platform notes

Appendix C: support

Write to support@cockpitai.io.

The published privacy policy is at cockpitai.io/privacy.

Appendix D: the Admin Health view (owner only)