Quick conclusion
On September 20, 2026, I tried using GitHub as a bridge between a regular ChatGPT conversation and my local Obsidian vault. In that session, ChatGPT used a connected GitHub tool to create a Markdown file in my private repository. A GitHub commit records the new file, and I later brought the change into my local Git history. The route worked in my environment: ChatGPT session → GitHub repository → local vault.
There is a catch. OpenAI’s current GitHub help page says the ChatGPT GitHub app only lets you read from your repositories and points editing and pushing work to Codex. I can report what happened in my session. I cannot offer the write step as a feature every ChatGPT reader can reproduce.
Why I tried the bridge
I run CBOEX Japan with an Obsidian vault containing article plans, research notes, and writing rules. A normal ChatGPT conversation is useful for discussing a draft, but it does not by itself place a Markdown file in the vault on my PC. I wanted to see whether GitHub could carry a small piece of work between that conversation and my existing local workflow.
The roles were straightforward: ChatGPT was the conversation surface, the private GitHub repository held versioned text, and Git on my PC brought an accepted change into the Obsidian vault. This was a file transfer experiment, not a test of ChatGPT controlling Obsidian or my computer directly.
What happened on September 20
I used a regular ChatGPT chat in a PC browser with a connected GitHub plugin. After reconnecting it, the session could read an authorized private repository and one of its Markdown instruction files. For the first write test, I chose a new Markdown file in an intake folder. That kept the experiment small and avoided editing an existing article or rule.
The session record describes a create_file action. GitHub then contained a commit adding the test file. I can verify the resulting file addition in Git history. Later, my local Git history incorporated that remote commit, and the Markdown file was present in the local vault. The file was subsequently moved into an archive folder, so its later location should not be mistaken for the original write destination.
Later in the same conversation, the chat record also shows update_file, create_branch, and create_pull_request actions. The matching branches, commits, and two pull requests exist on GitHub, and both pull requests were merged on September 24. Those persistent objects confirm the changes and the review step, while the action names come from the chat record. I do not have the individual action invocation IDs or raw responses needed to independently link every GitHub object to a particular tool call.
This is enough to describe an observed workflow in one account and session. It is a narrower claim than “the standard ChatGPT GitHub app can write to repositories.”
What GitHub did and did not prove
A commit is strong evidence that a file was added to a repository. It is not proof that ChatGPT directly edited my local vault. The local copy appeared only after a separate Git operation on my PC. GitHub’s stored result also does not, by itself, identify which ChatGPT action made it; the chat record supplies that attribution.
The first test landed on the remote main line. Other branches and pull requests in the later record do not retroactively make that first write a reviewed branch workflow. These are separate moments in the experiment.
The local side exposed another limit: my local main and the remote main had both moved, so git pull --ff-only refused to update. Git’s pull documentation says a fast-forward-only pull fails when the local branch has diverged from the remote one. I will cover the resulting Git recovery and verification problem in Part 2. Here, the relevant point is simpler: a Git-backed bridge needs an explicit intake process. It does not behave like a shared folder that quietly keeps both sides current.
Where the current docs differ
As of September 26, 2026, OpenAI’s GitHub connection guide says ChatGPT retrieves permitted repository content on demand so you can analyze, search, and cite code. Its FAQ says the GitHub app in ChatGPT only lets you read from your repositories and points readers to Codex for generating, editing, and pushing code. The guide also says GitHub availability depends on the plan, workspace, and product surface.
When I checked my ChatGPT interface on September 25, the GitHub plugin detail page displayed “Interactive, Write.” That label did not list a repository file action or establish that any specific write was available. OpenAI’s connected apps guide says permission settings only change when ChatGPT asks before acting; they do not grant an app new access. The difference between the documented standard app and my September 20 session remains unexplained.
A more recent run in my own environment also worked, but I have far less detail on it than on September 20, so this article relies on the dated September 20 record. If you want to try this, check the specific tools and approval prompts your own account shows before treating it as a repeatable setup.
A safer workflow next time
If I run this experiment again, I would design the handoff around review:
- Give the connected tool access only to the repositories the task needs.
- Put AI-written Markdown on a dedicated branch, if that tool surface actually supports writing and branch creation.
- Open a pull request and inspect the file diff, including the destination folder and any information that should stay private.
- Merge only after that review, then bring the change into the local vault with Git and verify the file on disk.
GitHub’s pull request documentation describes the review step. This branch-and-PR sequence is my next design, not the procedure I used for the first write test. I have not verified branch protection settings for this repository. A private repository alone would not settle the questions of access, data sent to the service, or what reaches my local files.
There is also a content boundary. My vault excludes some images, video, and PDF files from Git tracking. GitHub can carry only what is actually committed there. That is a choice in this vault’s setup, not a general limit of Git or Obsidian.
FAQ
Can ChatGPT write to my GitHub repository the way it did here?
I cannot promise that. The standard ChatGPT GitHub app is described as read-only in OpenAI’s current help page. My September 20 result belongs to a particular connected plugin and session. Check the actions exposed in your own product surface and the result of a small, authorized test.
Did ChatGPT edit my Obsidian vault directly?
No. The observed write was on GitHub. A separate local Git step brought the change into the vault on my PC.
Does a private repository make this workflow safe by itself?
No. Repository access, approval prompts, the files you expose, the branch used for writes, and the local intake check each matter. I would review the diff before accepting any generated Markdown as part of the vault.
Next steps
This test showed that a Markdown handoff through GitHub happened in my environment. It also showed why the exact ChatGPT tool surface and the Git intake procedure matter. Part 2 will look at what happened when the remote and local histories diverged, and how a clean Git status failed to answer the bigger question of whether every local file had been accounted for.