Steward
Sign in

Documentation › Contributor guides

Sign a CLA on a Steward repo

The Steward — CLA check on your PR is red. The repo requires you to sign its Contributor License Agreement before your PR can merge.

Background: the Gates concept doc covers what a CLA is + why repos use them.

Two paths: individual or corporate

Before you sign, figure out which path applies:

You're contributing as yourself

You're a hobbyist, a student, a solo Open Source Software (OSS) contributor, or an external contractor working on a private repo without your employer's involvement. Sign individually — covered below.

Your employer has (or could have) signed the CLA

You're contributing as part of your job, and your employer might have a corporate CLA in place that covers you. Don't sign individually before checking — a corporate signature is usually preferable because it covers all your colleagues at once. Read "Corporate CLAs" below first.

Individual: sign in ~30 seconds

The failure comment Steward posted on your PR has a link that reads:

To sign individually: open the CLA on steward-dev.ai and click I agree.

The link takes you to /app/cla/<repo-id> on steward-dev.ai. The page shows:

  1. The CLA text the maintainer committed to .steward/cla.md on the default branch.
  2. The repo's name + the maintainer's organisation, for context.
  3. An I agree button.

The flow:

  1. Sign in with GitHub if you haven't (the button redirects through GitHub OAuth — same flow as any GitHub sign-in).
  2. Read the CLA. Yes, actually read it. This is a legal agreement; the maintainer chose the text deliberately.
  3. Click I agree. Steward records the signature with a content hash of the CLA text you saw.
  4. Push to your PR (or wait ~10 seconds, then refresh). The Steward — CLA check re-runs and turns green.

You don't need to push a new commit; any push (or comment- triggered re-evaluation via /steward evaluate) re-runs the gate. The signature is recorded server-side; it's not coupled to a specific commit.

What gets recorded

The Steward server stores:

  • Your app.users.id (linked to your GitHub login).
  • The content hash of the CLA text at sign time.
  • The timestamp.

That's it. No other agreement detail; the legal hook is the content-hash record + the visible CLA text at sign time.

Corporate CLAs

Many companies have signed CLAs on behalf of their engineers so each individual doesn't have to sign separately. If yours has, your gate failure should clear automatically — but only if your commit identity matches the corporate allowlist.

The corporate allowlist matches contributors two ways:

  1. By GitHub login — your login is on the corporation's allowlist (e.g., bob-acme is on Acme's list).
  2. By commit-author email domain — your commit's author email is from a domain on the corporate allowlist (e.g., bob@acme.com matches the acme.com domain entry).

The CLA failure comment will mention the corporate path if it looks like one of these might apply but you're not on the list yet:

If an employer has signed this CLA on behalf of its engineers, ask the signatory to add the missing login(s) or email domain(s) to their allowlist at /app/cla/corporate.

Action: ask the corporate-CLA signatory at your company to add your login or email domain. They're the only ones who can edit the allowlist. Once they do, push to your PR (or comment /steward evaluate) and the gate re-runs.

Common confusion: GitHub noreply emails

If your commit author email is the GitHub-provided noreply form (12345+username@users.noreply.github.com), the corporate domain match won't fire. Fix the commit email:

git config user.email "bob@acme.com"
git commit --amend --reset-author --no-edit
git push --force-with-lease

Or ask the corporate signatory to add your GitHub login directly to the allowlist (no email-dependence then).

Your employer doesn't have a corporate CLA on this repo

That's fine. Sign individually via the link in the failure comment. The corporate path is an optimisation; the individual path always works.

Re-signing after the CLA text changes

If the maintainer amends .steward/cla.md on the default branch, the content hash changes. Your previous signature no longer matches; your next PR will show the gate as failed with a "re-sign required" message in the failure comment.

This is the correct behaviour — a contributor who agreed to v1 didn't agree to v2. Sign the new version (the link in the failure comment takes you to the current text).

For non-substantive amendments (typo fixes), some maintainers will grandfather existing signatures by policy. That's a maintainer-side decision; from your side, just sign again when prompted.

CLA enforcement modes

Some repos run CLA as block (failing gate prevents merge); others as flag (advisory, your PR can still merge). The failure comment will tell you which mode you're in:

  • Block mode: "This repo requires a signed CLA before this PR can merge."
  • Flag mode: "This repo asks contributors to sign its CLA. It's currently configured as advisory — your PR can still merge — but..."

In flag mode you can technically merge without signing. Most maintainers will still ask you to sign before approving — read their CONTRIBUTING.md for the local norm.

Privacy + data

What we store about your signature:

  • Your sign-time identity (GitHub login + email at the time).
  • The CLA text content hash.
  • Timestamp + IP + User-Agent (for the audit trail).

Visible to:

  • You — at /app/cla (your own signatures).
  • The maintainer — aggregated as part of the repo's signature roster; specifically, the maintainer sees that you signed but not your IP / User-Agent.
  • The corporate signatory (if you signed under a corporate CLA) — they see you as a covered contributor on their corporate roster.

You can delete your individual signatures from /app/cla → Delete my individual signatures. This emits a cla.signatures_deleted_by_user audit event. The deletion does not invalidate the historical cla.signed audit events — those persist as the historical record of "you agreed to v1 at time T", which is intentional.

Corporate signatures you signed AS the signatory are preserved — those represent the corporation's agreement, not yours individually.

What's next