create a .gitignore file within any .ipynb_checkpoints folder created

[itcarroll]

Problem

• I'm always frustrated when .ipynb_checkpoints show up in a git repository because they haven't been included in a .gitignore.
• I would like it if all .ipynb_checkpoints were ignored by git without users having to do anything.

Proposed Solution

• Have Jupyter create .ipynb_checkpoints/.gitignore whenever it creates an .ipynb_checkpoints folder.
• The content of the .gitignore file should be *.

Additional Context

Many tools that create folders in a project do this; for example, uv venv creates a .gitignore within the .venv folder it creates.

[shleshaG]

Hi @itcarroll

I’m preparing seriously for GSoC 2026 and have been actively exploring the Jupyter Server / JupyterLab codebase. I’d really like to work on this issue if it’s still open.

I’ve spent some time understanding the problem and the proposed solution. I agree that having .ipynb_checkpoints appear in git status by default is a frequent pain point, especially for new contributors, and handling it automatically at creation time would be a clean and user-friendly fix.

My current understanding / approach:
• The checkpoints directory is created by Jupyter when notebooks are saved.
• We could hook into the directory creation logic to automatically generate a .gitignore inside .ipynb_checkpoints with * as its content.
• This mirrors existing patterns used by tools like virtual environment managers that generate internal .gitignore files to avoid polluting user repos.

What I can work on next (if assigned):
• Identify the exact code path where .ipynb_checkpoints directories are created in Jupyter Server / JupyterLab.
• Prototype a minimal change that safely creates a .gitignore only when the directory is newly created (and does not overwrite user files).
• Add tests to ensure this behavior works across platforms and doesn’t introduce regressions.
• Update documentation or release notes if required.

I have prior experience working with Python codebases, Git/GitHub workflows, and debugging filesystem-related issues. I’m committed to following project conventions, writing tests, and iterating based on maintainer feedback.

If this issue is suitable for a newcomer contribution or GSoC-aligned work, I’d love to take ownership of it. Please let me know if you’d like me to open a draft PR or start with a design discussion first.

Thank you for your time and for maintaining Jupyter — I’m excited to contribute! 🙌

[itcarroll]

Thanks for describing the problem, potential solution, and a contirbution plan. I am not a maintainer, or even a contributor to this project, but I hope a maintainer accepts your offer and can support your work on a PR. From my experience, it may be hard to get feedback until you've opened a draft PR.

[krassowski]

I’m preparing seriously for GSoC 2026 and have been actively exploring the Jupyter Server / JupyterLab codebase

To be frank it does not look like there is enough capacity for Jupyter to apply for GSoC 2026 as per jupyter/governance#322.

I’d really like to work on this issue if it’s still open

Usually issues on which there was enough time to let maintainers/contributors discuss the idea are a better target for first contributions, but if that behaviour was opt-in and a PR came with solid tests and documentation then I would expect it to be reviewed eventually. Just setting expectations - repositories with more mature codebase may move slower than others.

[shleshaG]

Thanks for the clarification and for setting expectations.
I’ll proceed with a draft PR implementing this in a minimal and well-tested way, and iterate based on feedback if any.
Appreciate the guidance.