Conversation
pressing F for myself. |
|
@mitsuhiko this needs to be split into two PRs. the thing we want to fix first and foremost is approval on first load. once that works, we can talk about a "project local" settings. i'm not a huge fan of .pi.user tbh. we need to discuss how we want to do this. please remove the .pi.user stuff for now. |
badlogic
left a comment
There was a problem hiding this comment.
this looks good directioanlly, but i need a fresh brain to review it properly. biggest question is how this handles e.g. pi -session somesession that has a cwd outside the current cwd. i think the spaghetti in main doesn't account for that currently.
|
|
||
| if (!this.settingsManager.isProjectConfigTrusted() && hasProjectConfig(this.sessionManager.getCwd())) { | ||
| this.chatContainer.addChild( | ||
| new Text(theme.fg("warning", "This project is not trusted. Change with /trust"), 1, 0), |
There was a problem hiding this comment.
should probably say what this means, i.e. no project local extensions will be loaded.
| } | ||
| const projectConfigTrusted = this.options.forceProjectConfigTrust === true || selection.decision === true; | ||
| this.settingsManager.setProjectConfigTrusted(projectConfigTrusted); | ||
| await this.handleReloadCommand(); |
There was a problem hiding this comment.
this will reload extensions from .pi/, but will not trigger package installs defined in /.pi/settings.json. not sure what we want. package installs happen early on startup before interactive mode, so i'm now kinda questioning why all this is necessary in interactive mode at all.
|
gracias a todos por su tiempo y colaboracion 💯 |
|
Hello! I was also working on a similar feature following the poc i shared in the contributors channel on discord, here's the code and the sessions if you're intersted: aliou#1 + https://assets.aliou.me/share/traces/2026-06-04-pi-trust/index.html |
|
I wrapped this as a smaller implementation with different semantics than this PR. Main differences:
I intentionally left out the live reload/trust mutation path from this PR. If a project was trusted at startup, the potentially risky reads/extension execution may already have happened, so changing trust mid-session should not pretend to make the current runtime safe. Conversely, trusting an already-untrusted session should not start loading project inputs into a live runtime. The saved decision is for future sessions only. I also kept startup cwd migrations/settings lookup as-is. The runtime trust gate is applied after the final session cwd is known, which avoids prompting for the wrong folder when resuming or selecting a session from another cwd. This comment is AI-generated by |
This adds two things to the system as of today:
.pi.useris added as second folder that user extensions can be loaded from (these should never be extended).piand.pi.userneed to be approved on interactive loads on first load (or-fhas to be passed)This requires some further cleanup as parts of it are clanker generated without targeted review (particularly tests).