[FEATURE] notebook copy should include built-in resources

[hutch3232]

Use Case / Problem

My particular use-case (I could see many others) is to make a bunch of copies of a notebook, one for each participant in a Fabric training. Then they would have their own notebook to edit and run. I'm using the built-in resources component as part of the source notebook. When I use fab cp ... the copy of the notebook has empty built-in resources.

Proposed Solution

I'm not sure if it should be an additional argument or simply the standard behavior.

Alternatives Considered

No response

Impact Assessment

• This would help me personally
• This would help my team/organization
• This would help the broader fabric-cli community
• This aligns with Microsoft Fabric roadmap items

Implementation Attestation

• I understand this feature should maintain backward compatibility with existing commands
• I confirm this feature request does not introduce performance regressions for existing workflows
• I acknowledge that new features must follow fabric-cli's established patterns and conventions

Implementation Notes

No response

[microsoft-github-policy-service]

Thank you for submitting this issue, Paul (@hutch3232).
A member of the Fabric CLI team will review your submission and provide feedback shortly.

[github-actions]

AI Assessment: Needs Team Review

Handling built-in resources during notebook copying is a nuanced issue. The current fab cp command copies notebooks, but by default excludes or resets built-in resources, leading to empty resources in the copied notebook. Changing behavior to copy these embedded resources could affect semantics, backward compatibility, and user expectations—especially if built-in resources are workspace- or context-specific.

It's unclear if built-in resource duplication is always desirable, or if there are risks (e.g., resource conflicts, data leakage, permissions). This may require discussion around: (1) feasibility with Fabric APIs, (2) potential impacts on training workflows and regular notebook management, (3) flag design (e.g., an opt-in flag for deep copy of resources), and (4) impact on the resource hierarchy and permissions model as documented in the CLI hierarchy.

This request is valuable for training and onboarding use cases but warrants team-level review and a decision on default vs opt-in behavior, plus careful mapping of resource semantics.

Next Steps

🔔 Escalated to team — This issue requires team review and has been flagged for attention.

---

💡 If this issue requires the team's attention and was not escalated, you can tag @microsoft/fabric-cli-dev to notify the team.

[github-actions]

🔔 @microsoft/fabric-cli-dev — This issue has been flagged by AI triage as requiring team attention. Please review the assessment above.