# obsidian-github-copilot declares Apache-2.0, ships MIT, and files the licence as LICENCE.md

> Pierrad/obsidian-github-copilot puts GitHub Copilot inline completions and a note-linked chat inside Obsidian, with Mermaid rendering in chat responses and configurable suggestion scope, delay, and key bindings. It needs a Copilot subscription and a Node 22 path, its chat does not stream because an upstream Obsidian request is unfinished, and its licence is stated three different ways.

**Pierrad/obsidian-github-copilot** — A bridge between Obsidian and Github Copilot

- Repository: https://github.com/Pierrad/obsidian-github-copilot
- Stars: 498 · Forks: 60
- Language: TypeScript
- License: Apache-2.0
- Published: 2026-09-15 · Updated: 2026-09-15 · Language: en
- Canonical page: https://hysenlabs.com/projects/pierrad-obsidian-github-copilot

## Apache-2.0 in the metadata, MIT in the manifest, LICENCE.md on disk

This plugin states its licence three different ways and the README states none.

The repository metadata reports Apache-2.0, which is what the platform detected from the licence file. The package manifest declares MIT. The file itself is committed as `LICENCE.md`, with the British spelling, so a tool looking for the conventional `LICENSE` filename does not find it. And the README has no licence section at all, unlike most Obsidian plugins.

Those three are not reconcilable from the repository alone. A detected licence comes from parsing a file, so the metadata most likely reflects whatever text is in `LICENCE.md`, while the manifest field is what gets published to the plugin directory and what an npm install would read. If you are redistributing this or vendoring it into a larger work, that is the thing to resolve with the author rather than infer.

Two adjacent metadata fields are empty, which is a small sign of the same looseness. The `keywords` array in package.json is an empty list and the `author` field is an empty string, even though the plugin is published under a scoped name and its author maintains at least one of its own runtime dependencies.

None of this affects whether the plugin works. All of it affects whether you can tell what you are allowed to do with it.

## A manual install fails unless the folder is renamed to github-copilot

The normal install is two steps and the community plugin browser handles the awkward part for you: install the plugin through the Obsidian community plugins browser, then activate it in settings and configure whatever options need configuring.

The manual path has a trap that the README flags in a note.

If you install by cloning the repository or downloading the release files from GitHub, you have to name the plugin folder `github-copilot` for the plugin to work. The repository itself is called `obsidian-github-copilot`, so the folder name you get by cloning is wrong, and Obsidian identifies a plugin by its folder. Nothing throws an error; the plugin simply is not the plugin you installed.

There is a second manual step as well. Once installed, you go to the plugin settings and enter the path to the Node 22 binary, and the README tells you to find it by running `which node` in your terminal.

```bash
which node
```

So the plugin is not self-contained. It spawns a Node process it has to be told where to find, which is also why the package manifest points its `main` at a bare `main.js` at the repository root: that file is the esbuild bundle, produced by the build step, and it is not in the tree. What is published is compiled output plus a stylesheet, and what is in the repository is TypeScript source.

Sign-in happens after that, either through a modal asking you to sign in to Copilot, or through a notice saying Copilot is ready, which is what you get if you have signed in to Copilot previously in an IDE.

## The chat does not stream, and the blocker is an upstream request

The chat feature list has six ticked boxes and one empty one, and the empty one is the interesting one.

Ticked: chat works inside the editor, you can choose any model available in the Copilot Chat service, there is a chat history, notes are linked with double-bracket syntax in the chat, you can configure a custom prompt as a system message in the settings, and you can choose whether the enter key sends the message or adds a new line.

Empty: streaming the response from the API. And the reason is given rather than left blank. The README says it is waiting for `requestUrl` to implement streaming, and links a thread on the Obsidian forum asking for streaming support for that API.

So the reason is outside this repository. Obsidian plugins call out to the network through a host-provided function, and until that function can deliver a response body incrementally, a plugin cannot render tokens as they arrive. That is a platform limitation rather than an oversight, and the feature list is honest about it by leaving the box unchecked and citing the upstream discussion.

The practical effect is on feel rather than correctness. A long chat answer appears all at once, after the wait, instead of filling the panel. For a plugin whose chat is used to summarise notes with `[[wikilink]]` references, that is tolerable. For anyone asking something with a long answer, it is the thing they will notice first.

Note also that the model names in the usage example are `gpt-4` and `claude 3.7`. The feature list says you can choose among all models available in the service, so those are illustrative, but they are the illustrative names a reader copying the example will try first.

## Mermaid is the feature the README bolds, and it carries three runtime dependencies

One item in the chat feature list is written in bold while everything around it is plain: Mermaid diagram support, rendering Mermaid diagrams in chat responses.

It is the only feature singled out that way, and streaming, the feature that is missing, is not. So the priorities as written are diagrams over responsiveness.

The mechanism is straightforward. When Copilot replies with a Mermaid code block, the chat renders it visually instead of showing the source. You ask for a diagram and it appears. The listed diagram types are flowcharts, sequence diagrams, class diagrams, state diagrams, Gantt charts, and pie charts, with the list closing on and more, and the README states the diagrams adapt to the Obsidian theme so they follow light and dark mode.

The example in the documentation is a flowchart of a software development lifecycle, rendered as follows.

```mermaid
flowchart TD
    A[Requirements Analysis] --> B[Design]
    B --> C[Implementation]
    C --> D[Testing]
    D --> E[Deployment]
    E --> F[Maintenance]
    F --> A
```

The dependency list explains what that costs. Mermaid itself is a runtime dependency at a version 11 range. Rendering the surrounding Markdown needs react-markdown, remark-gfm for GitHub-flavoured Markdown, and react-syntax-highlighter for the code fences. And the two type packages for those, one for Mermaid and one for the syntax highlighter, are also runtime dependencies rather than development ones, so two `@types` packages ship to end users.

That is the price of the one bolded feature, and it is a real load for a plugin whose other headline is autocomplete.

## Node 22 at runtime, Node 16 types in the build

The runtime requirement and the build-time types disagree by six major versions.

The README requires Node.js 22 or later for inline completion, and asks you to configure the path to that binary in settings. The development dependencies pin `@types/node` to a 16 series. So the code is type-checked against a Node 16 API surface while it is required to run on Node 22.

The rest of the pinning is unusually exact. The two TypeScript ESLint packages sit at 5.29.0, `builtin-modules` at 3.3.0, esbuild at 0.17.3, tslib at 2.4.0, and TypeScript at 4.7.4, all without a caret. Runtime dependencies, by contrast, all use caret ranges. So the toolchain is frozen at specific versions while the libraries move, and TypeScript 4.7.4 is a release from 2022.

Set against that, one development dependency is declared as `latest`. The Obsidian typings, which are how a plugin sees the host API, float to whatever the current release is. A floating API surface checked by a four-year-old compiler is the combination most likely to produce an error that has nothing to do with the code you wrote.

The build script is a type check followed by a bundle, with the type check written using single-dash flags.

```json
"build": "tsc -noEmit -skipLibCheck && node esbuild.config.mjs production"
```

There is no test script at all in the manifest, and no test directory in the tree, for a plugin whose suggestion timing and key bindings are the parts users complain about.

## Two known issues, both about the environment around the plugin

The known-issues list has two entries and neither is a defect in the suggestion logic.

The first is the sandbox. If Obsidian was installed with Flatpak, the default binary path is not accessible inside the Flatpak sandbox, so the Node binary the plugin needs cannot be reached. The README's advice is to use NVM to handle Node versions, and it links the tracker issue for more detail. That is an environment conflict between two packaging systems, and the workaround is to change how Node is installed rather than anything in the plugin.

The second is key handling. Tab completion can be buggy in some cases, and the example given is inside bullet points in math mode. The cause given is plugin priority over the key bindings, which is the general Obsidian failure mode where two plugins want the same key and the order decides the winner.

What that tells you is that the binding layer is configurable and therefore contested. The inline feature list confirms it: you can configure your bindings to accept, dismiss, trigger, or partially accept suggestions. Four actions on the same key space is generous, and it is exactly why collisions with other plugins are the reported failure.

The rest of the inline configuration is worth knowing before you turn it on. You can set the suggestion generation delay, choose between automatic suggestions and manual triggering only, and choose between suggestions only in code blocks and suggestions in the whole note. That last one is the setting to think about for a notes application, since a vault is prose and a Copilot model completing your prose is a different act from one completing a code block. Folders and files can be excluded from generation.

## Two patch releases in fourteen hours, then five months without a tag

The release history is short and recent enough to date.

Three tags are visible: 1.2.2 on 2026-03-07, 1.2.3 on 2026-05-02, and 1.2.4 on 2026-05-03. The last two are fourteen hours apart, and 1.2.4 shipped two minutes after the last push to the branch. The branch is `master` rather than `main`, the repository is not archived, and nothing has been tagged or pushed since May 2026.

The version number is kept in step with Obsidian's plugin convention by a script rather than by hand. The `version` script in package.json runs a small Node program and then stages the two Obsidian metadata files with git.

```json
"version": "node version-bump.mjs && git add manifest.json versions.json"
```

That is the standard Obsidian arrangement, where `manifest.json` carries the display version and `versions.json` maps versions to minimum app versions, and both files are committed. The consequence is that an npm version bump reaches into git, so the release process has two tools moving two files and neither is the package manifest's own version field.

There is a `.cursor/` directory in the tree alongside a legacy `.eslintrc` and `.eslintignore`, a `.prettierrc`, an `.editorconfig`, and an `.npmrc`. There is no test script and no test directory. And the `format` script is worth a glance: it runs Prettier in write mode, then ESLint with fix, then ESLint again, so a format pass both changes files and verifies them in one command.

## Conclusion

obsidian-github-copilot is worth installing if you already pay for GitHub Copilot and want its inline completions and note-linked chat inside Obsidian, because the alternative is leaving the vault for a browser on every question about a note. It is not worth the trouble if you need streaming chat, a local model, or a build you can audit in an afternoon, since the chat is waiting on an Obsidian feature request and the package states its licence three different ways. Three things to check first. The licence is Apache-2.0 in the repository metadata and MIT in the package manifest, with the text committed under a British-spelled filename and no statement in the README, so settle that before redistributing anything. A manual install does nothing unless you rename the plugin folder to github-copilot, and it needs a Node 22 path typed into the settings by hand. And the build type-checks against Node 16 type definitions with TypeScript frozen at a 2022 release while the Obsidian typings float to whatever is current, which is a combination a new Obsidian API surface can collide with.

## FAQ

### What does the obsidian-github-copilot plugin need before it works?

A GitHub Copilot subscription and a network connection to send and receive data from the Copilot service. Inline completion additionally needs Node.js 22 or later, and you have to enter the path to that binary in the plugin settings, which the README suggests finding by running which node in your terminal.

### Why does a manual install of obsidian-github-copilot not show up in Obsidian?

If you clone the repository or download the release files from GitHub rather than using the community plugins browser, you have to name the plugin folder github-copilot. The repository name is obsidian-github-copilot, and Obsidian identifies a plugin by its folder, so the plugin silently does not load under the name the clone gives it.

### Does the obsidian-github-copilot chat stream its responses?

No. Streaming the response from the API is the single unchecked item in the chat feature list, and the reason given is that it is waiting for requestUrl to implement streaming, with a link to the Obsidian forum request. Answers therefore arrive complete rather than token by token.

### Can obsidian-github-copilot render diagrams in its chat panel?

Yes, that is the one feature the README highlights in bold. Mermaid code blocks in a Copilot reply are rendered visually, covering flowcharts, sequence diagrams, class diagrams, state diagrams, Gantt charts, and pie charts, and the diagrams follow the Obsidian light or dark theme.

### What licence is obsidian-github-copilot released under?

The repository metadata reports Apache-2.0, package.json declares MIT, and the licence text is committed as LICENCE.md rather than LICENSE. The README carries no licence section, so the three statements are not reconciled inside the repository.

## Sources

- [Issues](https://github.com/Pierrad/obsidian-github-copilot/issues)
- [License: Apache-2.0](https://github.com/Pierrad/obsidian-github-copilot/blob/master/LICENSE)
- [Pierrad/obsidian-github-copilot on GitHub](https://github.com/Pierrad/obsidian-github-copilot)
- [README](https://github.com/Pierrad/obsidian-github-copilot/blob/master/README.md)
- [Releases](https://github.com/Pierrad/obsidian-github-copilot/releases)

---

Hysen Labs editorial analysis, written from the project's own repository and release notes. Cite the canonical page: https://hysenlabs.com/projects/pierrad-obsidian-github-copilot