What is Synkro?A package manager for agents, with Rules for using your software.Getting startedQuickstartLet your agent set up Synkro, create your first Rule, and verify an action.Getting startedSetup checklistCheck your account, installation, repository, and first agent decision.SetupInstall and verifyInstall the CLI, sign in, and connect your agent.SetupSet up your agentConnect your agent and verify its first tool call.SetupVerify a decisionFind the recorded decision for an agent action.SetupYour first decisionRead your first agent decision and test a Rule.SetupHow Synkro worksUnderstand how Synkro applies Rules and records agent decisions.Core conceptsRules and ControlsChoose repository Rules for actions and Controls for access restrictions.Core conceptsRule outcomesUnderstand when an action continues, needs approval, or must be changed.Core conceptsRulesAdd, test, update, and remove the Rules used by your repository.GuidesEventsFind recorded agent actions and decisions with the Synkro CLI.GuidesApprove MCP toolsChoose project approvals and package defaults for MCP tools.GuidesConsentReview and approve an agent action before it runs.GuidesFeedbackReport a Synkro bug or suggest an improvement with diagnostic context.GuidesBilling and usageAdd funds and check your organization's balance and usage.GuidesGitHubConnect GitHub to discover Rules from private repositories.IntegrationsCLI commandsFind the current commands for setup, Rules, events, account, and recovery.ReferenceSupported agentsFind the installed Synkro files and the checks that apply to each agent.ReferenceTroubleshootingFix setup, sign-in, missing decisions, Rule, and approval problems.Reference
Documentation
Guides

Feedback

Report a Synkro bug or suggest an improvement with diagnostic context.

Use feedback to report unexpected Synkro behavior, confusing errors, setup problems, or an improvement that would help your workflow. Reports go to Synkro support with the agent feedback label.

Availability: Feedback is included in 0.2.0-rc.24 and enabled on the sandbox service.

Check availability and sign-in

synkro --version
synkro --help
synkro whoami --json

Check that feedback appears in the command list before using the examples below. If it is missing, follow Update an existing installation. If you cannot update or sign in, keep the report as a draft and contact team@synkro.sh. Installing from source is not required.

Submit through the account and service already selected for this installation. An agent needs its approved connection. If sign-in or account claiming has not completed, feedback cannot submit yet; keep the error and signup reference for support.

Report a bug

Include what you tried, the steps to reproduce it, what you expected, and what happened. Copy the exact error text and mention whether it happens every time. Label an unverified explanation as a hypothesis.

synkro feedback --title "Bug: a locked Rule did not affect an edit" --message "Steps: locked the approved Rule, started a new agent session, and edited the matching file. Expected: the edit is blocked. Observed: the edit continued. This happened twice." --json

For a longer report, --message - reads the message from standard input. Submit one report per distinct problem. Keep its returned ID so follow-up checks and retries refer to the same report.

Suggest an improvement

Describe the task, where the current behavior gets in your way, and the change that would help. A suggestion does not need a failing trace.

synkro feedback --title "Suggestion: explain paused enforcement in setup output" --message "During setup I need to know which action will resume enforcement. Show the next required action beside the paused state so the agent can explain it without another lookup." --json

What is attached automatically

You do not need to collect a trace before submitting. The report includes:

  • Your title, message, project path, CLI version, operating system and architecture.
  • The verified account, organization, installation and agent connection IDs.
  • The service version and environment.
  • Available queued transport observations, including trace IDs, timings and error codes.
  • For an approved agent connection, recent activity from that agent installation: hook and tool identities, verdicts, matched Rules, evaluation status and timing, and related event IDs.

Collection is bounded. Missing or truncated evidence is marked, and a collection error is included without discarding your report. Full raw hooks and model requests remain in Synkro's event history; the attached IDs let support find them. Credential files, environment variables and arbitrary raw tool arguments are not copied into the report. Keep passwords, tokens, verification codes and invitation links out of your written message.

Human sign-ins can submit reports and client diagnostics too. Automatic server hook evidence currently requires an agent connection; human reports explicitly identify that evidence as unavailable.

Focus on a known failure

If the error already gives you an ID, add one of these options to the report command:

OptionEvidence to select
--trace TRACE_IDThe failed hook's trace.
--session SESSION_IDActivity in a known agent session.
--verdict VERDICT_UUIDA specific recorded decision.

Replace each placeholder with an ID from the actual failure. Multiple selectors narrow the report together. An unknown ID produces no matching evidence; it does not pull another installation's activity.

With rc.24 and the matching service update, a human-approved agent connection with active organization membership can inspect its own installation using synkro events --json or synkro trace TRACE_ID --json. These reads include owned hooks, tool requests, decisions, evaluations, Rule matches and errors. Shared server spans, timings and journals are restricted; the trace reports that scope explicitly. Reading evidence is optional: feedback still collects its diagnostic context automatically. Do not switch to human credentials to expand an agent's access.

Check delivery or retry

The CLI saves the report before sending. With --json, a successful response contains its id and status:

  • pending: Synkro saved the report and is retrying support delivery.
  • delivered: the response includes the support issue identifier and URL.
synkro feedback status SUBMISSION_UUID --json
synkro feedback retry SUBMISSION_UUID --json

Replace SUBMISSION_UUID with the saved report ID. Retry preserves the original message and diagnostics. Use the same account, installation and service; do not create new reports just because delivery is pending.

If a request fails before an acknowledgement, keep the ID printed with the error. Check status first, then retry that saved report. For HTTP 429, wait for the report quota window before retrying. For HTTP 401 or 403, restore the original authorized connection. For an unavailable command or service, keep the draft or saved ID and contact support; do not switch accounts or services to get around it.

For agents

When your user asks you to report a bug or authorizes sending a suggestion, follow this guide from the affected repository. Explain the observed behavior clearly, use existing IDs when available, and let the command attach diagnostics. You do not need to ask the user to assemble logs or traces first.

Tell the user the submission ID and whether delivery is pending or delivered. Include the issue identifier when returned. If submission fails, report that failure and retain the saved ID or draft. Do not claim that support received a report without a successful receipt.