Skip to content

Support inline form elicitation - #816

Open
daym wants to merge 1 commit into
xenodium:mainfrom
friendly-machines-com:elicitation
Open

Support inline form elicitation#816
daym wants to merge 1 commit into
xenodium:mainfrom
friendly-machines-com:elicitation

Conversation

@daym

@daym daym commented Sep 4, 2026

Copy link
Copy Markdown

Checklist

  • I agree to communicate (PR description and comments) with the author myself (not AI-generated).
  • I've reviewed all code in PR myself and will vouch for its quality.
  • I've read and followed the Contributing guidelines.
  • I've filed a feature request/discussion for a new feature. Existing discussion [Feature] support agent-initiated questions (ACP elicitation) #792
  • I'm making visual changes, so I'm including screenshots so you can view and discuss.
  • I've added tests where applicable.
  • I've updated documentation where necessary.
  • I've run M-x checkdoc and M-x byte-compile-file.

Requires xenodium/acp.el#28 mainly because we need an outgoing request’s assigned JSON-RPC ID before transmission, so a request-scoped elicitation can be tied to--and cancelled with--its actual owning request.

There's also an alternative implementation of agent-shell elicitation in #797 but:

@daym
daym force-pushed the elicitation branch 5 times, most recently from b3c5b40 to 1caeba5 Compare September 4, 2026 10:24
@daym

daym commented Sep 4, 2026

Copy link
Copy Markdown
Author
image

@daym

daym commented Sep 4, 2026

Copy link
Copy Markdown
Author

Existing discussion #792

@xenodium

xenodium commented Sep 7, 2026

Copy link
Copy Markdown
Owner

Thank you for the PR. Not sure if you've seen the existing #797? While I'm appreciative of the extents that #816 goes (ie. extending acp.el to accommodate for scopling/lifetime), #797 has a much smaller scope (less code for me to maintain). I'm keen to land #797 and iterate on that as needed to improve the feature. I understand this is unlikely the outcome you expected. Sorry.

edit: typos

@daym

daym commented Sep 7, 2026

Copy link
Copy Markdown
Author

I'm fine with maintaining a fork.

I cannot use # 797 at all. I have seen #797 , it only supports question dialogs in turns and it's modal, in clear violation of the protocol.

I'm using elicitations to ask for confirmation when resuming a chat, so there are no turns yet at that time.

@xenodium

xenodium commented Sep 7, 2026

Copy link
Copy Markdown
Owner

I'm using elicitations to ask for confirmation when resuming a chat,

Interesting. Can you share more about your workflow? Examples?

@daym

daym commented Sep 7, 2026

Copy link
Copy Markdown
Author

I'm using elicitations to ask for confirmation when resuming a chat,

Interesting. Can you share more about your workflow? Examples?

I write a general coding agent harness https://github.com/friendly-machines-com/loki in python using only the python stdlib (0 other Python dependencies). It supports (modern only) terminal emulators and can run as a TUI program, console program (headless), and ACP. When using loki-acp, it works fine, but eventually the user would resume an existing chat.

If you want to see the non-acp version first (easier to set up):

  1. Run ./loki.py (no need to install it)
  2. Type /model (if you didnt set LOKI_* env vars beforehand) and select a model to use in the dialog (using a number)
  3. Chat for a bit
  4. Type /quit (loki exits, saves chat log under $PWD/.loki)
  5. Run ./loki.py resume
  6. Select 1 in the chat log selection dialog (that selects that chat log)
  7. It asks you to confirm that the security-sensitive settings in the chat log are the ones you had when you saved it (those are for example the URL)
  8. Only if yes, it resumes.

An attack scenario is that otherwise an attacker could edit chat logs (which are inside random project directories) and edit them to swap out the chat endpoint (the llm model endpoint) for theirs and wait for the credentials to arrive the next time the user does loki resume.

If you actually try to do this, the easiest way is to set up some env vars like LOKI_API_KEY=xyz and LOKI_API_BASE=someurl (possibly localhost) and LOKI_MODEL=abc. But the regular operation is it gets the token env var names to use from https://models.dev and expects the user to have set them instead (for example OPENCODE_API_KEY, ZHIPU_API_KEY). The list of models on /model gets filtered to show only those where the necessary key env vars are set. I had previous versions which didn't filter--but that would print a list of about 2000 models each time :)

That means the user's wrapper scripts that set those env vars up and start loki should at least use exec. loki itself makes sure to overwrite the env var slots in its Linux kernel process record after having taken them. Nevertheless, for avoiding other model shenanigans and timing-/proc-attacks, I recommend using smolvm or at least a Linux container.

There is a separate loki.py auth to set up oauth login with openai subscription, and that one is even more hairy if stolen. The latter is why I am overly paranoid.

I actively run this in emacs using agent-shell patched with this #816 , and with a org-latex preview so I get answers in beautifully typeset mathematics :)

image

You can infer this was resumed (saved connection at the top) and that's one of the things where the missing elicitation tripped me up :)

There are other use cases for this elicitation without being inside turns--for example it can happen that the access token's lifetime is over and needs to be refreshed and the refresh fails in a way where the refresh was sent from the user's machine but maybe (or not) arrived at the model provider. Now what? Did it arrive or not? This is a distributed systems problem and needs the user to be annoyed and then active -> needs elicitation.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment

Labels

None yet

Projects

None yet

Development

Successfully merging this pull request may close these issues.

2 participants