VS Code does not support absolute file path in github.copilot.chat.codeGeneration.instructions

[booch]

Select Topic Area

Bug

Body

I'm trying to set up Copilot in VS Code to have some default instructions for all the projects I work on. The github.copilot.chat.codeGeneration.instructions setting says I can reference an external file to give instructions. It does work if I give it a path relative to the project, but does not work if I give it an absolute path.

{
    "github.copilot.chat.codeGeneration.instructions": [
        {
            // This works, but is relative to the project root, so cannot be shared across my projects:
            "file": "test-instructions.md"
        },
        {
            // This does not work:
            "file": "/home/my-account/test-instructions.md"
        },
        {
            // I would expect this to be how it should work, but https://github.com/Microsoft/vscode/issues/2809 says extension authors need to handle `~` themselves until it's resolved:
            "file": "~/test-instructions.md"
        },
    ]
}

I note that the chat.promptFiles specifically calls out that it supports absolute paths in its example (although I have not tried it yet). So it seems like referencing files with absolute paths should be the norm. It'd also be great if you supported paths starting with ~. And if I can have a 🦄, variables in file paths.

PS. Why are some of the settings namespaced in github.copilot.chat and some in chat? Prompt files are definitely specific to Copilot chats.

[github-actions[bot]]

💬 Your Product Feedback Has Been Submitted 🎉

Thank you for taking the time to share your insights with us! Your feedback is invaluable as we build a better GitHub experience for all our users.

Here's what you can expect moving forward ⏩

• Your input will be carefully reviewed and cataloged by members of our product teams. 
  • Due to the high volume of submissions, we may not always be able to provide individual responses.
  • Rest assured, your feedback will help chart our course for product improvements.
• Other users may engage with your post, sharing their own perspectives or experiences. 
• GitHub staff may reach out for further clarification or insight. 
  • We may 'Answer' your discussion if there is a current solution, workaround, or roadmap/changelog post related to the feedback.

Where to look to see what's shipping 👀

• Read the Changelog for real-time updates on the latest GitHub features, enhancements, and calls for feedback.
• Explore our Product Roadmap, which details upcoming major releases and initiatives.

What you can do in the meantime 💻

• Upvote and comment on other user feedback Discussions that resonate with you.
• Add more information at any point! Useful details include: use cases, relevant labels, desired outcomes, and any accompanying screenshots.

As a member of the GitHub community, your participation is essential. While we can't promise that every suggestion will be implemented, we want to emphasize that your feedback is instrumental in guiding our decisions and priorities.

Thank you once again for your contribution to making GitHub even better! We're grateful for your ongoing support and collaboration in shaping the future of our platform. ⭐

[stellarpower]

github.copilot.chat.codeGeneration.instructions is showing up (As of 1.106.3) for me as deprecated in favour of chat.instructionsFilesLocations; however if I use the latter, it seems my file is being ignored (does not show up as used references). If I use the former, I presumably hit this issue.

A clear motivating example for this sort of functionality would be style guides. Yes, it makes total sense to override some things on a per-project basis, but at the same time when writing lots of crappy little scripts or jumping between many projects, it becomes a pain constantly having to overwrite the style the model defaults to, and I also don't want to litter my folders with redundant markdown files just for getting it to make small edits here and there.

Also another usecase might be to mark code written by the model. The flipside is that when I see snake case, I at least know I didn't write that and so to be more cautious and skeptical when coming back to something after a year and not being able to remember what the hell was going on. Might be nice to instruct it to mark code sections it has written with a comment or similar so that projects can differentiate between something written by a programmer and something written by the model.

[Sewaaa]

Copilot in VS Code reads prompt files from your workspace root.
Right now, it only supports relative paths in settings.
Absolute paths don’t work there, even if some docs show them in examples.
It’s a limitation on the extension side, not VS Code itself.

If you want shared defaults across projects, the options are:
Put your prompt file in each project (same name, relative path).
Or use a global snippet/shortcut to paste instructions when you start a chat.
Or make a small script outside Copilot to inject prompts per workspace.

About the namespaces in settings:
They split them because some configs apply to chat, others to completions or code gen.
It’s confusing, yeah, but that’s how they wired it for now.

[stellarpower]

Thanks; the separation makes sense, but it just then becomes hard to follow at times, especially when the newer-style settings seem not to work whilst the deprecated ones at least appear to be doing something. I get that that'#s always the way of things, tracking config changes needed to progress a project, but at the same time when the documentation isn't always complete it often means just giving up, sellotaping, and waiting six months.

On those workarounds, all can be done, but it's still annoying for me, and presumably the OP too. Personally I make a lot of throwaway windows, or work on single files and not an entire project/workspace. Copilot doesn't write good code for a larger project, so the majority of the times I am using it myself is for rubbishy devops scripts where I can just get it to do my work for me and I don't need to care if it's written a nice or horrible implementation. So I wouldn't want to have instructions littered around all over the place and hence why it would be much more useful to be able to pull things in from ~/.config or similar and have it apply every time. For now I've just opted to put them inline in my settings JSON, which isn't nice but the least bad of the workarounds available.