Where the code runs
By default a run executes on our infrastructure: your repository is cloned into a per-run workspace, the change is made, and the workspace is deleted when the run ends. Nothing is retained between runs of different organisations.
If your source cannot leave your own network, a self-hosted runner inverts that. You install it with one command on a machine you control, it polls us for work, and the clone happens on your hardware. The specification, the approvals, the comments and the audit trail stay in CodeLynq; the code never reaches our servers. The pull request is still opened server-side, so the formatting and the provider handling are identical either way.
One difference worth knowing before you choose: the automated gates that run before a pull request on our infrastructure — verify, self-review, security scan — are part of the hosted pipeline, and a self-hosted run goes from agent straight to push. If those gates are why you want the product, that is a real trade-off rather than a detail, and worth raising with us before you decide.
You can also supply your own model API key. Then the model spend sits on your contract with the provider, along with their retention terms, and we are not in that path at all.
Which model vendor sees your code is a choice too. Runs are dispatched to Claude Code, Grok or the OpenAI Codex CLI, set per organisation. If a procurement decision or an existing agreement points you at one vendor, that is a setting rather than a reason to rule the product out — and the spec, the gates and the pull request are identical whichever you pick.
Identity and access
Single sign-on over SAML 2.0 or OIDC, configured per organisation against your own identity provider. Once you set your email domain and switch enforcement on, password login stops working for that domain — there is no parallel credential left for someone to keep using.
SCIM 2.0 handles provisioning and deprovisioning from the same directory. Removing someone in your IdP removes their membership here. One honest limit: group membership does not confer a role. Everyone provisioned by SCIM lands as a plain member, and an admin promotes them. If your access model depends on directory groups mapping to permissions, that part is manual today.
Organisation-wide MFA can be required, and members who have not enrolled are blocked from everything except the enrolment flow itself, so turning it on does not lock out the people who need to comply. An IP allowlist takes CIDR ranges, IPv4 or IPv6, and where a user belongs to several organisations the most restrictive policy wins — one admin's rules are never weakened by a laxer organisation elsewhere. Roles are admin and member: deliberately two, not a permission matrix nobody audits.
Both of those gates apply to human sessions. A personal access token authenticates differently and is not subject to them, so if your policy depends on MFA or network origin covering every path, treat API tokens as a separate control and issue them accordingly.
What gets written down
Around a hundred distinct actions are recorded: logins, failed SSO attempts, MFA changes, member and role changes, token creation and revocation, SCIM operations, organisation settings, billing events, deployments. Each row carries the actor, the organisation, the entity, the client address and the user agent.
You can filter that log in the app, export it as CSV — up to fifty thousand rows, streamed, and the export is itself an audited event — or have each entry POSTed as JSON to an HTTPS endpoint you nominate, with four retries and exponential back-off. It is a generic webhook rather than a Splunk or Datadog connector: if you need a vendor-specific format, something on your side does the shaping.
A caveat we would rather you heard from us. Streaming carries events scoped to an organisation. A handful of account-level events — a login, a registration, an MFA change — are not organisation-scoped and stay in the log you query rather than reaching the stream. If your detection rules depend on authentication events arriving in your SIEM, this is the gap to plan around.
Retention is yours to set. The platform defaults are a year for audit entries and ninety days for run logs; both can be overridden per organisation, and a daily job enforces whatever you chose.
Credentials
Repository tokens, model keys, SSO client secrets and MFA secrets are encrypted at rest with authenticated symmetric encryption. The API never returns them — settings screens show whether a value is set, not the value. Passwords are hashed with bcrypt.
A run receives only the repository token and the model credential it needs. It never sees the platform's own database credentials or signing keys, because the agent executes repo-controlled code with a shell tool and anything in its environment is one command away from being read.
What the agent is allowed to do on its own
Nothing reaches your default branch without a person. CodeLynq opens pull requests and has no ability to merge them, which is a deliberate boundary rather than a missing feature.
The behaviours that could act unattended — iterating on failing CI, opening a fix from a production alert, triggering a deploy after a merge — ship switched off. You enable each one per project, and each carries its own ceiling: iterations are capped per run, alert-driven runs are capped per hour, and both count against the same quota as work a person started.
For live debugging against a real environment, the four capabilities are separately opt-in and fail closed. Log access, read-only database queries and shell commands each do nothing until configured. Database access rejects anything that is not a single read statement, and commands must match an allowlist you write — an empty allowlist permits nothing at all.
Data subject requests
A user can export everything held about them as a single JSON document, and can delete their account from the same screen. Deletion removes memberships, sessions and tokens outright and anonymises the account record itself, because tasks and comments reference it and cascading those away would rewrite history other people rely on.
Someone who is the last admin of an organisation is blocked from deleting until that is resolved, rather than leaving an organisation nobody can administer.
Getting it through review
Most security reviews ask a similar set of questions, and we would rather answer them with specifics than a trust badge. Tell us what your process needs — a questionnaire, an architecture call, a pilot on a repository that does not matter yet — and we will work to it.
Start that conversation, or read how self-hosted runners and environment access work in detail.