Is this ready for review? I see its still marked as a draft PR @harleylrn

@bpmct Will be ready Monday 😄
WE want to verify it again internally first 😄

@harleylrn

I would try and keep both the main.test.ts as well as the new amazon-q.tftest.hcl since the CI will currently only run the typescript tests in the module dir's

OK @DevelopmentCats
Will add it back 😄

Other than the above last nitpick comment I would say this looks good to me!

Probably going to need to run bun run fmt

Everything LGTM. I have been out for a bit, and I don't think I have actually ever pulled and tested this. So I'm going to approve it, and then pull it and test it out once or twice, and then I will publish it!

Thanks for the contribution @harleylrn !

@harleylrn

Something I notice when testing this. With the default agent configuration, it does not trust fs_write by default. So without extra configuration to the agent configuration by the user this would stop to prompt the user to trust the fs_write tool before making any changes which wouldn't really allow for a smooth experience out of the box.

In general I see why you would leave it with the default trusted tools, but it would be better to configure it with the minimal required tools for tasks, while allowing further configuration by the user if they would like to restrict or expand access for the agent.

I disagree on that
By default we are giving minimal possible access to the tools.
If person wanna trust the tools he has 2 options:

1. Provide his own agent config
2. Use the trust_all_tools parameter, which is false by default

In any case it should be the user's decision, not default

UPD: I also saw that the list of the variables somehow got vanished from the README. Will update it in a moment

UPD: I also saw that the list of the variables somehow got vanished from the README. Will update it in a moment

We do not put variables in readme as they already have their separate tab. There is certainly an opportunity there to improve the design there.

We do not put variables in readme as they already have their separate tab. There is certainly an opportunity there to improve the design there.

Got it, changed the README without the variables table.
I still strongly disagree to allow fs_write or all the tools by default. This is creating a huge security hole.
As a module provider, you should leave this decision in the hands of the end-user. If he wants to allow any tool that can have possible destructive effect - it should be his choice.
I added note to the README about that.
@matifali @DevelopmentCats

@harleylrn The goal for all Coder Agent modules to work out of the box with Coder tasks. And having fs_write is a required permission for the agent to autonomously work on a task.

This is the whole point of running agents in Coder as they can run in isolated sandboxes with higher autonomy.

@matifali @DevelopmentCats @keirans
Correct I'm totally agree on that.
But, and here is a huge but, the user should understand what he is doing and what is he allowing.
I'm not changing here any default behaviour of the AWS Q itself: by default fs_write tool is not trusted.

The task will still run by default, it will just stop and will wait for the trust approval from the user. I tested this as well 😄
If user want to test the task - this functionality is enough. If he wants to run it in production like - he will need to run with his own. configuration and not the default.

@DevelopmentCats can you test it one last time and then I think its good to merge?

@harleylrn can we add an explicit example on how to run the Q agent in full autonomous mode? similar to --dangerously-skip-all option of Claude Code.

Does it make sense?

@harleylrn can we add an explicit example on how to run the Q agent in full autonomous mode? similar to --dangerously-skip-all option of Claude Code.

Does it make sense?

Yes, I added this in the README:

Or you would like to have the full example under the ##Danger title?
@matifali @DevelopmentCats

Hey @DevelopmentCats @matifali

Just weighing in on the fs_write behaviour for this functionality in the module - I echo @harleylrn 's perspective on this behaviour being opt-in for the following reasons.

• The default behaviour of the Amazon Q software and agent is that the fs_write functionality is opt in per request as the default, as such, we shouldn't alter this functionality in this module without the user explicitly understanding the implications of doing so. (This also ensures that we align to the principal of least surprise.)

• The Amazon Q Security considerations and best practices documentation emphasises the approach to invoke actions with minimal permissions, and grant additional tool permissions only for the required duration, actions being performed or use case, It also highlights that if in doubt, reset the tool permissions to default, which as defined above that fs_write is opt-in.

• From an Enterprise and production perspective, security teams expect solutions to start with limited access, then add only the specific permissions needed. This allowlist approach aligns with the principle of least privilege and streamlines security reviews in customer requirements, rather than having an inverted model where you need to remove access if they arent required.

Cheers,

K

Or you would like to have the full example under the ##Danger title?

Yes a full example would help a lot.

Added comments and examples with the trust_all_tools trues option
@DevelopmentCats @matifali