Docs | SigDek

Get started

Sign in with GitHub, Google or a link emailed to you, and name your team. The 14-day trial starts then.
Install the recorder in a repository or as a plugin (below).
On each developer machine, run npx sigdek login and approve it in the browser.
Use Claude Code or Cursor as usual. Records appear in the dashboard within a minute of each session.

Install the recorder

In a repository, for everyone who clones it

npx sigdek init
git add .claude .cursor .sigdek
git commit -m "Record agent activity with SigDek"

This adds hooks to .claude/settings.json and .cursor/hooks.json, keeping anything already there, and writes a small launcher to .sigdek/. The launcher downloads the recorder version pinned in .sigdek/recorder.lock on first use and checks its SHA-256 before keeping it. Developers install nothing.

Claude Code and Cursor read these files only where a session starts (for Cursor, the workspace's root folder), so a session started in a subfolder of the repository isn't recorded unless that person also has the plugin.

On Windows, Claude Code runs hooks through Git Bash; without it, Claude Code uses PowerShell, where SigDek records nothing and no rule applies. Cursor on Windows runs hooks through PowerShell, which can't run the default hooks, so Cursor records nothing there either. For Cursor on Windows, npx sigdek init --powershell writes the Cursor hooks as PowerShell commands; Claude Code's hooks don't change. The hook file is committed, so this applies to everyone who uses Cursor in that repository, and it breaks Cursor's hooks for anyone there on macOS or Linux. Use it only where every Cursor user is on Windows.

As a Claude Code plugin, for one person in every repository

/plugin marketplace add tektonsoftware/sigdek
/plugin install sigdek@sigdek

The plugin downloads the recorder version pinned in its own lock file and checks its SHA-256 the same way. Records stay on the machine until it's connected to a team.

The Cursor plugin

SigDek's Cursor plugin isn't listed on the Cursor Marketplace yet. Until it is, Cursor teams use npx sigdek init in the repository, above.

Getting the command

npx sigdek … works anywhere Node.js is installed, with nothing to install. To install the sigdek command instead, use whichever you already have:

npm	`npm install -g sigdek`
Homebrew	`brew tap tektonsoftware/sigdek https://github.com/tektonsoftware/sigdek` `brew install sigdek`
Scoop	`scoop bucket add sigdek https://github.com/tektonsoftware/sigdek` `scoop install sigdek`
winget	`winget install TektonSoftware.SigDek` Each release reaches winget a few days after it's published, once Microsoft has reviewed it.
Go	`go install github.com/tektonsoftware/sigdek/cmd/sigdek@latest`

npm, Homebrew, Scoop and winget install the binaries published with every release, alongside a checksums.txt, on GitHub; go install builds the same source on your machine. The rest of these docs write npx sigdek; with the command installed, drop the npx.

Connect a machine

npx sigdek login

This prints a code and opens the dashboard. Check the code matches, choose the team, and approve. The machine receives a token that can only upload records and receive your team's rules: it can't read your team's data or sign in as you. Uploading starts from the moment the machine is connected; anything recorded before stays on the machine.

Signing in this way is the only way a machine starts sending records and receiving your team's rules. Agents on machines no one has signed in with sigdek login, such as Cursor's cloud agents, CI runners and hosted sandboxes, record only on that machine and send nothing to SigDek. Only the built-in rules apply there, and they block nothing.

To disconnect a machine, run npx sigdek logout on it, or use Disconnect on the People page. logout forgets the token and asks SigDek to revoke it; if the machine is offline, that request can't get through, so use Disconnect as well. Records already uploaded stay. The recorder keeps recording on a signed-out machine; if it signs in to the same team again, those records upload then, and sigdek login says how many.

To hand a machine to someone else, disconnect it on the People page, then have them run npx sigdek login on it. Records from before the handover stay under the previous person; a connected machine can't be taken over, even by an admin.

What a record holds

The recorder writes a record when a session starts or ends, when a prompt is sent, when an action finishes (it ran, failed or was refused by the agent), and for subagents and, in Claude Code, settings changes. The check before an action runs writes a record only when a rule blocks it or the action changes SigDek's own setup; that one is recorded as attempted before it runs, followed by its result when the agent reports one. Any other action someone declines at the agent's permission prompt leaves no record. The end of an agent's turn writes nothing. A record holds the person, the machine, the agent with its model, and its version where the agent reports one (Cursor reports both; Claude Code reports only the model), Claude Code's permission mode, the session, the repository, and for an action, its kind (shell command, file read, file edit, web request, MCP tool, other), the tool's name, the command, file path or URL, the result, how long it took and which rule matched.

Prompt text is never recorded, only its length and a SHA-256 hash. The hash can confirm a guessed prompt, so a short or common one like "yes" or "run the tests" can be worked out; a long one can't be recovered. File contents and command output are never recorded. The full tool input is kept only as a SHA-256 hash, which can likewise confirm a guess; when a secret was stripped from the action, the hash covers the stored, stripped form instead. Secrets are stripped from commands, paths and URLs on the machine before anything is written; that's best effort, so treat commands as sensitive. Paths inside the repository are relative to its root; your home directory shows as ~.

Each record carries the SHA-256 of the record before it on the same machine. Once records reach SigDek, any later change, gap or deletion shows up in the report's Integrity section. The local log has no secret key, so before upload someone with access to the machine could rewrite it consistently; that's why the proof starts at upload, which normally happens within minutes. The schema is published with the recorder.

Rules

A Flag rule marks matching actions in the activity log and the report. A Block rule stops the action before it runs, shows your message to the agent and the developer, and records the attempt as Blocked by rule. Machines pick up rule changes with their next upload. Until a machine is connected, a built-in set flags common risky actions and blocks nothing.

A rule matches when every condition you fill in matches:

Kind: one or more of shell command, file read, file edit, web request, MCP tool, other.
Command: a pattern found anywhere in the command. terraform destroy* matches cd infra && terraform destroy -auto-approve.
File path: a pattern for the whole path or its end. * stays within one folder, ** crosses folders: **/.env*.
URL: a pattern found anywhere in the URL.
MCP tool (as server/tool) and Tool name (the agent's own name for the tool, like Bash): the whole name, so Write doesn't match TodoWrite; add * for more. Cursor's general tool hooks, which SigDek uses, don't name an MCP tool's server, so for Cursor only the tool part is matched.

Start a pattern with re: for a regular expression (RE2 syntax, so no lookarounds). A rule with no conditions matches nothing. Every change is kept with who made it, and the report's Controls section lists them.

Block rules read the whole command, both as the agent sent it and as the shell reads it (continued lines joined, quotes and backslashes removed, spaces squeezed), so padding and quoting don't hide a command from them: rm -rf and 'rm' -rf still match rm -rf*. Rules catch an agent's mistakes; they aren't a sandbox. A command put together at run time, such as X=rm; $X -rf, can't be seen through.

Reports

Owners and admins generate a report for any period up to 13 months, in whole days in the team's time zone. It usually takes under a minute and produces a PDF and a CSV of every record in the period. A report never changes once made.

The six sections, each mapped to the SOC 2 criteria it supports:

Inventory: each person with the agents they used and how many machines; each machine with its name, operating system, owner and recorder version; the repositories seen, with record counts; and the MCP servers in use (Claude Code names the server; Cursor's general tool hooks, which SigDek uses, don't).
Recorder coverage, per person and per machine: whether each connected machine's recorder sent records for each working day (Monday to Friday, in the team's time zone). It measures the recorder, not the person. The recorder writes records only during agent sessions, so a working day without agent use has no records, the same as a day the recorder was off. Two or more working days in a row with no records from one machine are listed as a silent stretch. Days marked as leave for the machine's owner are left out: they don't count as silent and don't break a stretch. Public holidays are working days here unless marked as leave. Counting starts the day after a machine connects and stops the day before it's disconnected, and members with no machine are listed as not enrolled.
Activity, per person and per repository: sessions, commands, file edits, web requests and MCP calls.
Sensitive actions: counts per rule and outcome, with up to five examples for each rule. Every matching action is in the CSV.
Controls: the rules in force during the period, rebuilt from the rule history, and every change made in the period, with who made it and when.
Integrity: every record's hash recomputed from the copy SigDek stored when it arrived, its stored fields compared with that copy, chain links checked across the start and end of the period, and any breaks listed as ranges.

Every report also states what it can't show. Anyone in control of a machine can switch the recorder off: by removing the hooks or the plugin, turning hooks off in the agent's settings, pointing the launcher at another program with SIGDEK_BIN, or working in a repository without SigDek's hooks on a machine without the plugin. A session started in a subfolder of a repository set up with sigdek init is recorded only if that person has the plugin. Recorder coverage lists a machine that stops recording for two or more working days in a row. A single working day without records counts as a silent day in the report's machine table but isn't listed, and looks the same as a day without agent use; switching off for one session or one repository won't show. Built-in rules flag common agent edits to SigDek's own setup. Files attached to a Claude Code prompt with @ and Cursor's inline Tab completions aren't recorded. Agents on machines no one has signed in with sigdek login, such as Cursor's cloud agents, CI runners and hosted sandboxes, record only on that machine, send nothing to SigDek and get only the built-in rules, which block nothing. And a record shows what an agent did, not whether the resulting code is correct or secure.

Checking a report

Anyone who receives a report can check it at app.sigdek.com/verify. Their browser computes the file's SHA-256 and asks SigDek whether it generated a file with that fingerprint; the file itself isn't uploaded. A single changed byte gives a different fingerprint.

Team, email and seats

Members see activity and reports. Owners and admins also change rules, generate reports, invite people, mark leave and manage billing. A seat is anyone on the team or invited to it. One account can own up to five teams, and be a member of any number. Mark leave on the People page, or from recorder coverage on the Overview, so days away show as leave rather than as gaps.

People sign in with GitHub, Google or a sign-in link emailed to them. A link works once, for 15 minutes, and the first one an address uses creates its account. An invitation goes to the address it names, and accepting it needs an account signed in with that address.

What SigDek emails

Every email comes from notifications@sigdek.com, goes to one person, and ends by saying why they got it. Replies reach support@sigdek.com. There are no images, tracking pixels or tracked links, and reports are never attached.

Sign-in link	When you ask for one on the sign-in page.
Invitation	When an owner or admin invites you: who invited you, to which team, the role, and a link that works for 7 days. Settings, Members shows whether each invitation was emailed, and owners and admins can resend it or copy its link. Invitation emails have limits: per team, 50 an hour and 3 to one address a day (20 a day in all while the team is on its trial); per person inviting, 20 a day across their teams; and 10 a day to one address from all teams together. Past a limit, the invitation is still made and its link can be copied, and the Members page says why it wasn't emailed.
Reports	To whoever generated a report, when it's ready or couldn't be generated: the period, the summary and a link to the Reports page.
Machines	To the machine's person and the team's owners and admins, when a machine is connected or handed over, and when it's disconnected on the People page, with `sigdek logout`, or because its person left or was removed. Removing someone with three machines sends one email listing all three.
Rule changes	To owners and admins, including whoever made the change: one summary about ten minutes after rules change, listing every change in that time, Flag or Block, who made it and when.
Trial and billing	To owners: about three days before the trial ends, when it ends without a plan, and when a subscription ends or goes unpaid. Each says what keeps working (recording, past reports, exporting records) and what stops.

Everyone chooses, for each of their teams, which of the report, machine, rule-change and billing emails they get, under Settings, Email. Sign-in links and invitations always go.

On a day SigDek reaches its own sending limit, it holds invitation and notice emails back so that sign-in links keep working. A held-back invitation can still be copied from the Members page, which says why it wasn't emailed.

Commands

`sigdek init`	Add SigDek's hooks to the current repository. `--remove` takes them out, and `.sigdek/` too once no hooks use it.
`sigdek login`	Connect this machine to a team.
`sigdek logout`	Disconnect this machine: forget its token and ask SigDek to revoke it.
`sigdek status`	What is set up and working, and what isn't.
`sigdek log`	Recent records from this machine.
`sigdek verify`	Check the hash chain in this machine's local log. SigDek's copy is what proves records weren't changed after upload.
`sigdek flush`	Upload now. Normally automatic.

Run them with npx sigdek …, or install the command.

Troubleshooting

Start with npx sigdek status. Errors inside the recorder never block an action; they're written to ~/.sigdek/errors.log. Local records are in ~/.sigdek/log/, one file per month. If recorder coverage shows a gap on a day someone used an agent, check that the session started at the root of a repository with SigDek's hooks, or that the plugin is enabled.

Still stuck? Write to support@sigdek.com with the output of npx sigdek status.

Removing SigDek

In a repository: npx sigdek init --remove, then commit. For the plugin: /plugin uninstall sigdek@sigdek. On a machine: npx sigdek logout, then delete ~/.sigdek. To delete your team's data, write to support@sigdek.com from an owner's address.