copying-flags-across-projects

This skill guides you through duplicating a feature flag from a source project into one or more target projects within the same PostHog organization.

• The user asks to "copy a flag to another project", "duplicate this flag", or "sync a flag between projects"
• The user wants to promote a flag from a staging project to a production project (or vice versa)
• The user wants to replicate a flag configuration in a different workspace and keep cohort dependencies intact
• The user is working around the absence of true environments by using projects-as-environments

• Cross-organization copy is not supported. The endpoint requires source and target projects to belong to the same org.
• Bulk copying every flag in a project. The tool copies one flag at a time. For batch copies, loop through flag keys; each call is independent.
• Cleaning up old or stale flags — see the cleaning-up-stale-feature-flags skill instead.

• Cohorts are remapped automatically. When the source flag references a cohort, the endpoint creates or reuses an equivalent cohort in each target project and rewrites the flag's filters to point at the target-project cohort id. You don't need to handle this — but tell the user it's happening so they understand the new cohorts that may appear in the target.
• Encrypted payloads are preserved. Remote-configuration flags with encrypted payloads keep their encryption when copied; the payload is re-encrypted under the target project's key.
• Scheduled changes copy with cohort remap too. If copy_schedule: true, any scheduled cohort references are remapped just like the live filter conditions.
• Auth requirements. The user's API key must include explicit feature_flag:write (or feature_flag:*) scope. A *-only key will be rejected — this endpoint is gated by an INTERNAL viewset and * consent does not satisfy it. Team-scoped keys cannot reach this endpoint either; an org-scoped or unscoped key is required.
• Editor access on the source. The user must have at least editor-level access on the source flag's team. The endpoint enforces this via PostHog's access control before copying.
• Per-target access on targets. Targets the user can't see are silently dropped from the result; targets they can see but lack edit rights on appear in the failed array with a permission error.
• No undo. A copy creates a new flag in the target (or overwrites an existing flag with the same key). Always confirm with the user before issuing the copy, especially when the target is a production project.

User: Copy the new-checkout flag from project 12345 to project 67890.

Agent: Looking at the source flag in project 12345.

(calls posthog:feature-flag-get-definition)

The new-checkout flag is currently a boolean at 25% rollout in project 12345, with no cohort filters and no scheduled changes. I'll copy it as disabled in project 67890 with no scheduled changes — this is the safer default. Confirm?

User: Yes, but enable it in the target.

Agent: Got it — enabling in the target.

(calls posthog:feature-flags-copy-flags-create with disable_copied_flag: false, copy_schedule: false)

Done. Created flag id 99887 in project 67890 (active: true). No failed targets.

• posthog:feature-flags-copy-flags-create — performs the copy. Required fields: feature_flag_key, from_project, target_project_ids. Optional: disable_copied_flag, copy_schedule, copy_dependencies.
• posthog:feature-flags-copy-dependencies-check — previews what a copy would do to the flag's transitive flag dependencies. Copies nothing. Call it before every copy; it returns an empty result when the flag has no dependencies.
• posthog:feature-flag-get-all — find a flag by key/name in a given project when the user only gave a friendly name.
• posthog:feature-flag-get-definition — fetch the full source flag (filters, variants, cohort references, encryption flags) so you can preview before copying.
• posthog:projects-get — list projects in the active organization, used to resolve and validate target project ids.